It will that, unless you tweak stuff (writing files in /sys/*, or in the kernel) to permit running at 400/133 rather than capping at 330/220; if the DSP task can run smoothly at 133, that would increase the available CPU cycles.

(I've heard a rumor that the voltages are the same for 400 and 330, and that 400/133 is actually lower power consumption because of the lower clock on the DSP... I don't know how true that is.)

The /sys/ tweak, unfortunately, can't simply remove that cap; it just locks it in 400/133 regardless, until you set it back to automatic control. By tweaking the kernel (and recompiling), though, it can be set to scale without the DSP-usage cap. I think qwerty12 has done this, to name one...


Oh, BTW, Igor's slides on this. Slide 15 has the OP table, but the whole thing makes for a good read.

With regard to the quality of A2DP/SBC, I'm still not sold on it. I do wonder if this is because the Linux implementation is not optimal though (e.g. I can't see that it does variable bitpool size between frames, which is allowed for by the spec). It has some odd aural artifacts, some songs sound odd (they go faster and slower, only very slight but can be heard), I don't know where this problem stems from, but I'd like to fix it if I can work out how.

On to the DSP task. I've no idea of DSP power consumption, it would be nice to see some Nokia documents about this... anyone...?

My hope it that we can either:
1) reduce power consumption while just listening to mp3s by using a hopefully more efficient DSP task to take load off the ARM (and drop the ARM speed). It will take testing to see if this is the case
2) Reduce the load on the ARM so it can do more useful things (like XVid decoding). This really requires that we push the ARM back up to full speed, and the DSP down to 133MHz. I'll do myself a patched kernel asap and see whether the task can run at this speed. If not, then I'll try to make it run faster. Patches and help welcome of course

And last but not least, I did it just for the hell of it

Thanks Benson for some insights.

I was wondering what tasks the DSP (or ARM core) needs to do when supporting A2DP? THe MP3 (or whatever) decoding from file to audio is done with DSP in "normal" mode (headphones or speakers). With A2DP, does it need to encode it again into "A2DP compatible" stream? Or is it so that if the output is not going to speakers or headphones it is not supported function, and therefore it has to be done using its own decoder using "raw CPU horsepower"?

I propably could have found some answers by googling around... but thought this is easier...

The ARM only has to copy data to and from a buffer, all of the SBC encoding is done on the DSP. Bluez and probably mplayer + mad decoder do of course still run on the ARM so it's not left twiddling its thumbs

I don't have access to power consumption figures, so this may be the case. No idea.

P.S. I'm thinking of converting the current SBC encoder (the ARM one) to use floating point (i.e. VFP) and see how fast that works. I'll keep you informed as I progress.

Yes, the PCM stream (which comes from the MAD decoder built into mplayer) feeds it with PCM data which it converts into an SBC stream for output to the headset.

Note that we, unfortunately, can't do mp3 decoding on the DSP and then use those data (as they are fed straight to the audio codec for output). There is hope for the future with OpenMAX, but for the time being we need to use an ARM-based MP3 decoder (or write ourselves a DSP-based one which passes the data back to the ARM side for re-use.

Ah... good point WRT mp3 on DSP; I'm used to mp3 on ARM (mpd is libMAD, too), so I didn't even think of that. I hadn't even realized that the DSP MP3 codec didn't send it back to ARM anyway.
(I had assumed it did, and that the ARM was responsible for routing it to whichever output(s)...)
So I learned something today.

Thanks for the explanation lardman - I had the same query as tz1 - what happens after I install your package ? Now thats clear.

Another question though - so A2DP will still be limited using mplayer as the output program - just as Johnx's hack was applicable for ...
Its not as if any audio program will now be able to support a2dp.

Is that right ?

Any program which uses Bluez to perform the SBC encoding will use the DSP if you install the packages from dsp-sbc. So mplayer will work, as will any other program which supports A2DP (i.e. most of the 3rd party media players - Canola, UKMP, etc.)

Iirc, there is also a GStreamer component in there to do SBC encoding, so this should be useable with the media player (will need some fiddling with the media player conf settings, I've no idea how), or you could make your own pipeline in a terminal.

Do anybody know to use headphone buttons?
Line from my syslog when I press pause:
Jul 8 12:28:03 Nokia-N810-23-14 audio[9546]: Received AT+CKPD=200

Any program that can do alsa output, I think...