vampirefrog wrote:
After struggling with the WebAudio API and seeing how crappy support is currently (Firefox kinda works, but Chrome has not worked properly for me, no IE support), and looking at your project, it seems the best back-end is indeed one of sink.js or XAudioJS.
Chrome 34.0.1847.131m has some jittery sound for me, but that's partly due to the window not being focused combined with my crappy connection. I don't currently have Firefox on my dev machine, but I might put it back eventually.
vampirefrog wrote:
I'm not sure how good an idea is to port chips to javascript by hand, so using emscripten is a more practical choice for a full VGM player at this point.
If it works, fantastic!
Personally, I want to have hand-editable files for easier future maintenance, which is one of the reasons I don't use a build system like grunt or something to combine everything into one large file. There previously wasn't decoupled audio cores in JavaScript form, hence me writing them from scratch.
vampirefrog wrote:
Also, I've noticed you want to add decompress(). Is that for vgz files? In the particular setup of the packs project, that won't be needed, since we'll be sending the vgm data uncompressed, but the http request itself can be gzipped. We can just do that from php no problems.
Yes, for VGZ processing. I'm building this for SMSPower to use as well (which they technically can if they don't care about YM2413 playback yet) and eventually Project2612, so it needs to be able to load a pre-existing VGM file (compressed or uncompressed) from the same domain (uses AJAX, so subject to cross-origin restrictions by default) and play it all client-side without being dependent on anything special (all the dependencies like jQuery are front-end deps). SMSPower hosts all their soundtracks and in zip format, so that's also a bonus (don't yet know of a client-side 7z parser for the vgm7z packs, though; that would be server-side :/ ).
vampirefrog wrote:
So, it looks like you're on the good path with the way you've written things so far. If you choose to focus on vgmrips, I suggest you begin with the most used chips ... - NES APU, YM2151, AY8910 and HuC6280. That way you will have big coverage. If we cover the first 6 chips, we'll have over 800 packs covered out of ~1.1K.
Once I finish v1.50 parity (PSG, YM2413, YM2612, YM2151), then I'll focus on vgmrips-popular chips first, yes.
vampirefrog wrote:
Also, as a bug report, the player does not work on chrome, and I'm using latest stable chrome. It works on firefox. What I've found is that the chrome web audio api has a bug in which onaudioprocess() does not get called for a ScriptProcessor node. What you can do is force the backend to flash for chrome, and add an option to choose/force the backend in the UI.
Also, the sound is very skippy on IE unfortunately

IE likely uses the Flash fallback that XAudioJS provides. Once I do the cleanup rewrite and increase buffer sizes that might be resolved. Increasing the buffers sizes might resolve the Chrome issue as well, though I'm actually getting playback on mine.
vampirefrog wrote:
It has also occurred to me that if we write the chip code carefully, it might work in ActionScript as well, so we can have the playing part directly in flash, where we might get better results with the playback, and we can just use the UI in javascript and just send control signals to the flash app. Later, when the WebAudio API stabilizes (or when we're on firefox, where it seems to work fine), we just serve the plain JS. But otherwise, serve the flash app and have a JS interface to it. As we've seen, all the chip emulation web players use flash one way or another.
I'm not touching Flash. Anyone else wants to port my code to ActionScript, be my guest, but I'm not going to be the person to do it.