Yet another test build. The changes are:
-Increased sound buffer size. Now the sound crackling should be gone.
-Increased overall sound volume (it was too low). Now it sounds louder.
I believe you've traded off audio underruns for some very noticeable video-to-audio lag.
Trying out Ohboy 20140903_test33, I do hear multiple underruns per second (10 or more). On today's 20140904_test10, the sound lags a lot from the video, but it has no crackling.
I am testing in Pok?mon Yellow. In Pewter City, with the Pok?dex open, I press A on an entry that is neither seen nor caught, and it makes a "ding" sound. On a Game Boy, I could make the dings synchronise to the music by pressing A also in sync (yeah, I did that sometimes), and in 20140903 I can to an extent, but in 20140904 I can't.
Same thing in the Pok?mon Center dialogue box after pressing A.
In your commit 587dbc7
, you increased the PCM_FRAME constant to 1024 from 512, which was fixing the underruns by giving the hardware more time to report that its buffer was getting low. I think that's required for the GCW Zero - ReGBA with a 512 sample buffer, for example, didn't get enough time to put new samples in either.
But the PCM_BUFFER constant is still 4096, and main.c line 1451, in pcm_submit
if (pcm_buffered>=1) while(pcm_buffered == pcm_bufferlen);
... is how the application knows how many frames ahead it must emulate in order to try to keep PCM_BUFFER samples buffered, and how it synchronises on audio. That means it's emulating frames 93 milliseconds (4096/44100 of a second) ahead of the audio playback.
I'd recommend trying to lower the value of PCM_BUFFER for the GCW Zero, to either 3072 or 2048 (both multiples of PCM_FRAME).
[Currently, I believe the ring buffer handling is very broken and will not handle PCM_BUFFER not being a multiple of PCM_FRAME. Try tracing in your head what will happen to this code (main.c:1461..1468)
when there are 2048 samples buffered, pcm_bufferlen is 2560, and you're trying to add 1024 samples to it... The buffer write position (pcm_head) will only be put back to the start ONCE when the loop ends and has already tried to write 512 samples past the end (3072 in total). Memory corruption will result in a possible crash.]