Rockbox

Tasklist

FS#6023 - ADX decoder

Attached to Project: Rockbox
Opened by Adam Gashlin (AdamGashlin) - Monday, 18 September 2006, 21:42 GMT
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Here's an ADX decoder (4-bit ADPCM with looping, used in video games, from CRI middleware) for rockbox. I'd like to add some more configuration and features but I thought it'd be good to get it out there for testing. I've had it tested on an iPod Photo and Video.
The adx.c file goes in apps/codecs. The patch was generated against the most recent CVS and seems to work out.
   adx.patch (5.3 KiB)
   adx.c (8.6 KiB)
This task depends upon

Closed by  Rani Hod (RaeNye)
Monday, 25 September 2006, 16:13 GMT
Reason for closing:  Accepted
Additional comments about closing:  Thanks!

If you have any more changes, please feel free to reopen/open a new task.
Comment by Adam Gashlin (AdamGashlin) - Monday, 18 September 2006, 21:55 GMT
Some sample ADXs can be found here:
http://rotb.mgbr.net/music.htm
Comment by Rani Hod (RaeNye) - Wednesday, 20 September 2006, 13:17 GMT
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.
Comment by Rani Hod (RaeNye) - Wednesday, 20 September 2006, 13:20 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 20 September 2006, 17:53 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 20 September 2006, 22:35 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Thursday, 21 September 2006, 03:42 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Thursday, 21 September 2006, 04:28 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Thursday, 21 September 2006, 20:59 GMT
Crap, it happened again, not sure what the problem is...
Comment by Adam Gashlin (AdamGashlin) - Friday, 22 September 2006, 05:57 GMT
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
Comment by Rani Hod (RaeNye) - Friday, 22 September 2006, 09:34 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Friday, 22 September 2006, 10:21 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 24 September 2006, 07:37 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 24 September 2006, 08:44 GMT
one more potential for disaster handled.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 24 September 2006, 09:48 GMT
sigh... something is clearly still wrong.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 24 September 2006, 13:17 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 24 September 2006, 14:17 GMT
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.
Comment by Adam Gashlin (AdamGashlin) - Monday, 25 September 2006, 11:38 GMT
Being a bit more careful on errors, cleaned up comments.

Loading...