Rockbox

Some sample ADXs can be found here:
http://rotb.mgbr.net/music.htm

Tested on X5 (sim & dap), works well.
Player stays at 45 MHz and PCM buffer stays almost always full.

Note to author: please limit lines to 80 characters and avoid using CR/LFs.

I do have a problem with looping.
IMHO it should respect Repeat settings (i.e., loop only if repeat=one).

Please revise and I’ll commit.

Thanks for testing, I hadn’t considered using the repeat setting to control looping, I’ll see what I can do with it. I have also found a bug with looping that I have to fix, should have a new patch (also with CRLF fixed) later today.

Ok, I fixed a number of problems (mono ADXs were wrong, bitrate reporting was wrong), and the looping now works as follows:
If repeat=one it will properly loop the current track endlessly. Otherwise, it will repeat the looped part twice and then fade out over five seconds, as is common on soundtrack CDs.
Also straightened up and commented more, and now included adx.c in the patch.

   adx2.patch (16.3 KiB)

Every once in a while the playback seems to lose sync and I get a lot of loud static. I’m testing a fix for this now.

OK, I’ve been running the fixed version (checks after every read to ensure we’re still in sync with the stream) for a while now and didn’t notice any problems (would show up after about 12 minutes of play before), so I’m hoping the problem is solved. If I do run into it again I’ll note it here.
Here’s the new patch.

   adx3.patch (16 KiB)

Crap, it happened again, not sure what the problem is…

I am thinking that this might be a bug related to preloading the next track. I can reproduce it with the following procedure:
1) start playing a looping adx in repeat=one mode
2) near the middle of the track switch to repeat=none
3) a bit after the loop, when the correct name for the next track is loaded, things get nasty

I tried the adx3 patch and I still don’t like how the looping is done in repeat != one mode -
instead of displaying the played length (i.e., a little more than twice the real length) it wraps to 00:00 on the second playback.
That also means FF/RW control is hindered.

Also, IMHO fade-out should be governed by crossfade settings…
here you have a double fade when you have crossfade on.

Ok, I will see what I can do about these other issues, my concern at the moment has been for the bug I’ve been running into, I’m working on another patch to the playback code which will prevent looped files from being overwritten. Not sure quite what form it will take yet, though.

Here we go, a workaround for some problems with the playback code within the codec itself (some jiggery-pokery to ensure the entire track is buffered, so looping is all within the buffer and the prebuffering doesn’t get in the way). The length and elapsed time display is now as it should be, and seeking should work properly. Fade-out is still a firm 10 seconds, I don’t think crossfade should have any effect on the decoder.

   adx8.patch (18.8 KiB)

one more potential for disaster handled.

   adx9.patch (18.8 KiB)

sigh… something is clearly still wrong.

Whew. I sat down, looked things over, explained it to someone else, and found the bug. It was my own mistake.
This updated patch should be all you’ve ever dreamed of. I know it’s a weight off my chest.

   adx10.patch (18.8 KiB)

Found an easily fixed bug, looping tracks of length less than the fade length would end up resetting the fade counter on each loop and never ending.

   adx11.patch (18.8 KiB)

Being a bit more careful on errors, cleaned up comments.

   adx12.patch (19 KiB)