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]

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.

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.

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.

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]

1) Is it the native Rockbox AAC decoder that's used, i.e. not the Nero decoder?

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...

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 :-)

Not that I know of. But it wasn't that long ago that it was made more efficient.

3) Can you point me at the Rockbox source code that handles output buffering/processing?

dsp.c and pcmbuf.c

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.

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.

3) Can you point me at the Rockbox source code that handles output buffering/processing?

Might be easier to just look at the wrapper files in apps/codecs/ to see where decoded audio data actually ends up.

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.

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?

[OldSchool]

Lear:

I'm not sure whether I'm handling these quotes correctly - please bear with me if I mess it up:

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...

My bad, I didn't ask quite the right question. By "Nero decoder" I meant the neroAacDec.exe, that came in the zip file from Nero, along with the AAC encoder (neroAacDec.exe) that was used to create test files for the timing tests. I didn't realize that RB FAAD was also from Nero. Is it possible the two are the same animal? (I'll look into this)

From what you and Saratoga have said, it seems the best approach would be to look at the AAC decoding. Where can I find info on the "ffmpeg AAC decoder" you mentioned?

Saratoga:

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.

I was also thinking that any compression scheme based on a (modified) DCT - all of the ones used in RB AFAIK - must have frequency spectrum information available in the compressed data files. I don't know enough about the file formats or the DCT (yet), but I plan to investigate some.

Multiple IIR filters would be a good method, and has the advantage that it would operate on the output stream - therefore independent of the compression technique. Most of my DSP experience is with FFTs and FIR filters, so this could be an interesting departure. I gather there is IIR filter code already in RB (for the equalizer?), can you point me at the source?

Lear and Saragota

Thanks much for your help, I have lots to look at and think about.

Later...









_{edited to make the quotes read right. Hope Oldschool doesn't mind}

[Lear]

Have you been working on the ffmpeg AAC decoder?  Can you tell me more about its status?

No, I haven't. Just read a little about it on the ffmpeg project's mailing lists. And that was a while ago, so I don't know much about the current status.

My bad, I didn't ask quite the right question. By "Nero decoder" I meant the neroAacDec.exe, that came in the zip file from Nero, along with the AAC encoder (neroAacDec.exe) that was used to create test files for the timing tests. I didn't realize that RB FAAD was also from Nero. Is it possible the two are the same animal? (I'll look into this)

Not the same exactly, but neroaadec could (and probably does) use the same decoder library. One difference is that in Rockbox, certain AAC profiles have been disabled.

From what you and Saratoga have said, it seems the best approach would be to look at the AAC decoding. Where can I find info on the "ffmpeg AAC decoder" you mentioned?

Heard of Google?

[OldSchool]

Saratoga:

I've taken another look at the frequency spectral display idea again. I fear the design of the IIR filter implementation, using fixed point arithmetic, is beyond me unless I can get access to some design tools (possibly Matlab or Labview). I'll have to put it on the "Back burner" for now.

[saratoga]

Saratoga:

I've taken another look at the frequency spectral display idea again. I fear the design of the IIR filter implementation, using fixed point arithmetic, is beyond me unless I can get access to some design tools (possibly Matlab or Labview). I'll have to put it on the "Back burner" for now.

Never done filters in fixed point, but I doubt its that difficult.  I think you can design then in fp, then change all the multiplies to calls to a fixed point multiply routine (you can steal them from several of the codecs, wmafixed.c/h in the wma codec for instance).  Finally, make sure to convert your input samples from rockbox into whatever fixed format you're using.

[OldSchool]

Actually, fixed point filter design and implementation is generally considered (so I'm told, I've never done it either) to be much more difficult because of arithmetic over/under flow, saturation, quantization noise, scaling etc etc. As it turns out, I do have access to some design tools (and I'll try your suggestion about wmsfixed.c/h - thanks), so there's still hope...

Cheers.

[saratoga]

Actually, fixed point filter design and implementation is generally considered (so I'm told, I've never done it either) to be much more difficult because of arithmetic over/under flow, saturation, quantization noise, scaling etc etc. As it turns out, I do have access to some design tools (and I'll try your suggestion about wmsfixed.c/h - thanks), so there's still hope...

Cheers.

I don't think thats going to be a real issue here.  You're not building high order filters and you don't care about quantization error since your display will only have a handful of levels.  I think this application will be more tolerant then what most people need to design for, so you'll be able to get away with a lot more.

[OldSchool]

I did some fiddling with the filter designer (Matlab) and, if I start with 7 bands, centred on 40, 150, 400, 1K, 2.4K, 6K and 12.5 KHz (numbers from an old JVC cassette deck), I can use one low pass, one high pass and five band pass IIR filters.

Using elliptical filters with 1dB passband ripple, about 30 down in the stop bands, I can get what looks like fairly good roll-off with 6th order bandpass and 3rd order high/lowpass filters.

Anyway, that'll be my starting point. Next I'll try the fixed point conversion process on   the filters and see where that leads. If nothing else, I'll at least I'm learning the design tools.

If anyone is still following this thread, I'd be interested in comments/suggestions.