Not that anyone really cares, but I finally figured out the problem. And I spent a good deal of time hitting myself in the head for not noticing it sooner. The decoding worked fine, but rather the ringbuffer i put the decoded audio into had a slight bug. When it looped, it skipped over a byte of data (a ++i where I should have had a i++), and thus caused the offset you see below.
Thank you all for all the great help & support.
Reza
Reza Naima wrote:
Woot.. Making progress, finally -- though I'm not happy I'm having to resort to this. I did a byte by byte comparison of the madplay output and the output of my code... It's identical up to byte 0x4800 ...
My code :
00047f0 0095 ff69 0199 fe51 00d1 fedf ff20 006a 0004800 6600 2afe fa01 b5fe 9800 38ff 3400 a1ff 0004810 2500 95fe a901 0ffd 8302 74fe 1801 1f00 0004820 1000 1b01 e0ff 2300 43ff d200 03ff 3100 0004830 fa00 0eff ab00 05ff 4b00 4eff 6500 66ff
madplay :
00047f0 0095 ff69 0199 fe51 00d1 fedf ff20 006a 0004800 fe66 012a fefa 00b5 ff98 0038 ff34 00a1 0004810 fe25 0195 fda9 020f fe83 0174 0018 001f 0004820 0110 ff1b 00e0 ff23 0043 ffd2 0003 0031 0004830 fffa 000e ffab 0005 ff4b 004e ff65 0066
It remains out of sync until 0x0005a00...
The ranges it falls out of sync are :
04800 - 05A00 09000 - 0A200 0D800 - 0EA00 ....
All of which have a length of 4806 bytes, and happen at a regular interval of every 18432 (0x4800) bytes. Every time I get a callback to the output function, I get sent 4806 bytes -- this is also the same size as the buffer on the audio device, so I'm gessing the number isn't random.. Now to figure out what? As the pattern is regular, I could potentially compensate for it, but that seems plain ugly..
-r