Originally Posted by Estel

Wait, wait - audacity records from alsa external USB soundcard without problems in ED? I must have missed it. It's great news!

I wonder if totemplayer (with leetnoob's hacks to enable accelerated playback in it) in ED can easily use external sound card. Will try to check that, as time permits (not to much time those days, hardly enough to keep in pace with TMO and great ideas like that).

/Estel

Originally Posted by Estel

Finally I got time to unplug all cables from my desktop, and test Audigy 2ZS Video Editor with N900 - fpp was right, in fact it works as audio device (+ 4 port, powered USB 2.0 HUB, that is bundled inside), leaving only video capabilities for proprietary drivers = inaccessible.

smplayer is great mplayer front-end available from repositories. Of course, as it's still mplayer, it doesn't allow to use DSP assist in decoding... Yet, its using GUI and settings, to allow doing every thing that you can do with mplayer via terminal (at least, things that I'm aware of), adding to it every function that You would expect from GUI media player, like manipulating playlists, normalizing volume etc.
it's no different when it comes to selecting output audio device - I was able to choose my USB sound card via GUI drop-down list. Fortunately, no one decided that this option should be cut off while porting to Maemo "as no one could ever use it at the time of porting [it seems to me, that it was ported before hostmode become available]" - kudos for original creator/porting dev.

Furthermore, in my case it uses exact same amount of CPU time to decode, as when using N900's internal DAC. To be precise - mplayer process itself uses more CPU with external DAC, yet, with internal DAC, CPU cycles are "divided" between mplayer and pulseaudio. I've tested many times, and result were the same - 60-61% @500 mhz when decoding Q=6, VBR, lowpass=20kHz ogg file. At first, this part of my findings seems to be opposite to Oblomow research, yet, I'm not sure if "dividing" CPU cycles between mplayer and pulseaudio (when using internal DAC) was considered there (?).

Originally Posted by jerryfreak

for some background on similar application, many of us have been recording 24-bit 96khz spdif with dell axims for almost a decade using a PDAudio compact flash card audio interface. ive used this same card to record to a $200 old notebook with a cfcard/pcmcia adapter and alsa drivers with ecasound command line. this was before the dawn of decent USB audio solutions, of which there are now many...

Originally Posted by fpp

Interesting find... although of course it just means that if we could use the DSP *and* bypass PA, then we would use even *less* CPU cycles that the stock media player :-)
Also, CPU decoding is very dependent on the codec type and its settings : flac, mp3 and ogg will have different CPU usage patterns for example. And also flac 0 vs. flac 8, or mp3 128k vs. mp3 320 vs.mp3 VBR0, etc
I wonder (but this is just a wild guess) if DSP decoding would prove less variable.

Originally Posted by kirillkk

By the way, what are you trying to achieve?
If the goal is lower power consumption, then CPU load indicator is not the best thing to look at. Because ARM core is not the only consumer, not to mention linux cpu load statistic won't give a complete picture of ARM core usage.

Originally Posted by Oblomow

To try this, just type the above in an xterm and play something back through the stock media player.