Support and General Use > Audio Playback, Database and Playlists
Audio drop-outs when playing AAC files on Sansa E260 (Nero codec)
OldSchool:
Hello,
I'm new to Rockbox and audio compression codecs, so please feel free to point me elsewhere if that's more appropriate (I don't mind a little, or even a lot of, "leg work").
This came about when I went through the exercise of contributing results to the RB Wiki page "Comparison of Available Decoders Across Targets" for the Sansa E260 (RB version; r15975M-071229 - see results at
http://www.rockbox.org/twiki/bin/view/Main/CodecPerformanceComparison). I went through the procedure as described in the Wiki page, generated all of the test files (except WMA) using "encode.bat", and ran the Test Codec plugin successfully. I won't give any more detail here (it's all on the Wiki page), but the test includes files encoded using FLAAC, LAME (.mp3), MPC, Vorbis (.ogg), Wavepack (.wv), MPC and, finally, the Nero AAC (.m4a) codecs. All are generated from the same WAV file - about 176 seconds of stereo data - at various (encoding) bit rates.
All of the files that were encoded using the Nero AAC codec experience audio "drop outs" of about 1 second duration, every few seconds, regardless of the encoding bit rate, when played back on my E260 target. All of the other test files seem to play fine on the target (though I confess, I haven't listened to them all the way through, just long enough to be sure they don't show the same problem :-).
I tried playing the same suite of test files using Winamp - all seemed to play fine, including the Nero-encoded files. Winamp identifies the Nero files as: "Audio MPEG-4 AAC LC".
My first thought is that the AAC decoder is not "keeping up" in real time on the E260. Does this seem reasonable? The Wiki test results show decode times of between 1.55 and 1.72 times real time, depending on the sample rate, for the Nero files.
I'm interested in AAC codecs, in general, and in using the Nero codec with Rockbox, but obviously not until I can find what's causing these drop-outs. Any suggestions, information, technical details, links - I can even read (and write) C source code if that helps - will be much appreciated.
Thanks for reading this far, and Happy New Year! :-).
Lear:
--- Quote from: OldSchool on January 01, 2008, 02:56:44 PM ---My first thought is that the AAC decoder is not "keeping up" in real time on the E260. Does this seem reasonable? The Wiki test results show decode times of between 1.55 and 1.72 times real time, depending on the sample rate, for the Nero files.
--- End quote ---
Yes, that's possible. The decode times are for the actual decoding only. Other things takes processing time as well, in particular things like the equalizer, crossfeed and other sound processing options. Even the WPS can have an impact here, but the only thing to really worry about there is if it uses peak meters.
--- Quote ---I'm interested in AAC codecs, in general, and in using the Nero codec with Rockbox, but obviously not until I can find what's causing these drop-outs. Any suggestions, information, technical details, links - I can even read (and write) C source code if that helps - Â will be much appreciated.
--- End quote ---
Try disabling all sound processing (resetting the settings is an easy way to do that) and make sure the WPS doesn't use peak meters. That should allow the files to play properly. Then you can try adding the sound processing stuff one by one, to see how much you can use without problems.
OldSchool:
Disabling the peak meter definitely improves the situation. There was only one drop-out at the lowest bitrate, more at higher bit rates, but not nearly so many as when the peak meter is displayed. That seems to verify the hypothesis.
A few more questions (I'll try to dig up the answers on my own as well):
1) Is it the native Rockbox AAC decoder that's used, i.e. not the Nero decoder?
2) Are there any known optimizations that could be made to the peak meter display to load the processor less? (I really like the peak meters on my WPS :-)
3) Can you point me at the Rockbox source code that handles output buffering/processing?
I have ambitions of putting a frequency spectral display of some kind on my WPS (the Sansa factory code has one), but it's starting to look like that may be too much processor loading. Any other information/suggestions welcome.
Thanks for your help.
Lear:
--- Quote from: OldSchool on January 02, 2008, 01:12:35 PM ---1) Is it the native Rockbox AAC decoder that's used, i.e. not the Nero decoder?
--- End quote ---
Not sure if I understand your question, as the decoder is in Rockbox (it has to be). However, the decoder is FAAD, which is copyrighted by Nero AG...
--- Quote ---2) Are there any known optimizations that could be made to the peak meter display to load the processor less? (I really like the peak meters on my WPS :-)
--- End quote ---
Not that I know of. But it wasn't that long ago that it was made more efficient.
--- Quote ---3) Can you point me at the Rockbox source code that handles output buffering/processing?
--- End quote ---
dsp.c and pcmbuf.c
--- Quote ---I have ambitions of putting a frequency spectral display of some kind on my WPS (the Sansa factory code has one), but it's starting to look like that may be too much processor loading. Any other information/suggestions welcome.
--- End quote ---
Either use a format that decodes faster (e.g. Vorbis) or try to optimize FAAD (which hasn't been optimized much for Rockbox) - or help complete the ffmpeg AAC decoder. :)
saratoga:
I don't think peak meter loads the CPU very much. In the long term, finishing the dual core support will probably resolve these issues, at least on PP targets like the Sansa V1s.
--- Quote from: OldSchool on January 02, 2008, 01:12:35 PM ---3) Can you point me at the Rockbox source code that handles output buffering/processing?
--- End quote ---
Might be easier to just look at the wrapper files in apps/codecs/ to see where decoded audio data actually ends up.
--- Quote from: OldSchool on January 02, 2008, 01:12:35 PM ---I have ambitions of putting a frequency spectral display of some kind on my WPS (the Sansa factory code has one), but it's starting to look like that may be too much processor loading. Any other information/suggestions welcome.
--- End quote ---
A dozen channels shouldn't be that CPU intensive. Just use a couple IIR bandpass filters of low order and only update a couple times a second.
Lear:
Have you been working on the ffmpeg AAC decoder? Can you tell me more about its status?
Navigation
[0] Message Index
[#] Next page
Go to full version