Use -Ao Oss In Mplayer For Better Performance

[Spirit]

Legend sucks, stupid gnumeric.
The defaults blue is the higher one, -ao oss -vo omapfb is the lower one. To be able to use omapfb you need to "echo 4000000 > /sys/class/graphics/fb1/size" ( http://www.elinux.org/BeagleBoardFAQ#omapfbplay_mmap_fails ), I have no idea about this. Be aware that on average the simple -ao oss is using less cpu. Do not take small differences too serious. I am not sure the -vf eq2 is where it belongs.

Sadly the 480p Big Buck Bunny files are exceeding 800 pixel width, so I used http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_640x360.m4v (H264 and AAC, evil).
There was occasional hiccups/freezes during playback.

This is not scientific at all, I only used one file and one play. I noticed 5-10% less cpu usage with -ao oss with other files (also music playback of course) though so I suggest you change your ~/.mplayer/config to it.

Please notice that the y axis is only showing a small snippet.

I am not sure why vf=eq2 is in the config. Does it do anything without parameters? According to the manpage it is terribly slow.

The cpu spike at the beginning is interesting, it happens for other videos too. I was playing from SD card (Class 6), maybe caching?

 

[Spirit]

Yes, in ~/.mplayer/config

 

[Exophase]

Performance is better by going from OSS emulation to ALSA instead of straight to ALSA? Makes you wonder what the performance would be like using native OSS..

 

[notaz]

I'm guessing ED's software volume control config is the culprit of this, which is bypassed when using OSS emulation.

 

[Spirit]

That is normal. mplayer's "your system is too slow to play this" message also suggests it.

 

[Exophase]

I'm guessing ED's software volume control config is the culprit of this, which is bypassed when using OSS emulation.

That makes sense. Userspace mixing and per-thread volume control can be nice but for Pandora I think we're best off having those in the kernel. IMO the sound system should be doing:

a) If only one source is active and it's using one of TWL4030's supported frequencies data should be written directly to I2S with hardware volume control
B) If multiple sources are active at same frequency (will be typical if people play nice) apply mixing + software volume using NEON code in kernel
c) If multiple sources are active and using different frequencies resample and apply mixing + software volume using NEON code in kernel

Mixing in kernel reduces latency and improves response time.

fwiw, I don't think TWL4030 provides useful enough hardware mixing (just amongst four input channels that can do different DACs, so for channel balance basically).. but if you have to interleave data for mixing anyway actually mixing it is probably faster.

 

[notaz]

I just tried playing BigBuckBunny and could not reproduce this at all, all output methods (alsa, sdl, oss) give me ~70% CPU usage.

That makes sense. Userspace mixing and per-thread volume control can be nice but for Pandora I think we're best off having those in the kernel. IMO the sound system should be doing:

I partially agree but if you ever looked at ALSA code you would probably not want to mess with it. I know you'll suggest OSS4 but porting to that is also significant effort, and all my personal projects are already starving because of pandora firmware work (it's probably time take a break from that anyway). Also last time I used OSS4 it had pretty incomplete ALSA emulation and many programs broke, but this could have changed by now I guess.

fwiw, I don't think TWL4030 provides useful enough hardware mixing (just amongst four input channels that can do different DACs, so for channel balance basically).. but if you have to interleave data for mixing anyway actually mixing it is probably faster.

Not sure if you are aware that OMAP's McBSP (not i2s, but kinda equivalent) is connected directly to DAC, so only hardware volume control possible is volume wheel. TWL4030 only provides the clock, and takes care of line/mic in.

 

[Spirit]

I just tried playing BigBuckBunny and could not reproduce this at all, all output methods (alsa, sdl, oss) give me ~70% CPU usage.

Weird! Did you give it some time to settle? I always played in fullscreen, maybe that matters a bit?

edit: Before you ask, I used 500MHz.

 

[notaz]

Ah, I only noticed the scale now (difference is ~3-4%), obviously my method of looking at top output is too crude

 

[Exophase]

I partially agree but if you ever looked at ALSA code you would probably not want to mess with it. I know you'll suggest OSS4 but porting to that is also significant effort, and all my personal projects are already starving because of pandora firmware work (it's probably time take a break from that anyway). Also last time I used OSS4 it had pretty incomplete ALSA emulation and many programs broke, but this could have changed by now I guess.

How much is Pandora relying on straight ALSA right now? Apps using SDL won't need to be changed, obviously neither will ones using the OSS emulation. Seems if this can be done earlier on it'll cause less problems, but for now maybe we should advise using abstractions where possible?

Not sure if you are aware that OMAP's McBSP (not i2s, but kinda equivalent) is connected directly to DAC, so only hardware volume control possible is volume wheel. TWL4030 only provides the clock, and takes care of line/mic in.

Alright, so TWL4030's audio DACs and output filtering aren't being used. This isn't really a big deal, NEON can do volume and mixing very quickly, and if necessary resampling won't be a big hit either.

Maybe we should start at least assessing OSSv4 to see what kind of impact moving it is - if you're just using McBSP and writing to a DAC then your "sound card" is pretty much like a DMA DAC no? The McBSP setup stuff should be elsewhere in the kernel and it's not overwhelmingly complex (I've used McBSP on TI's DSPs and have looked at it on OMAP3, although I know it's a little worse there). It should be possible to port some existing OSSv4 code with only a few small changes.

 

[notaz]

you're just using McBSP and writing to a DAC then your "sound card" is pretty much like a DMA DAC no?

Yup.

The McBSP setup stuff should be elsewhere in the kernel and it's not overwhelmingly complex (I've used McBSP on TI's DSPs and have looked at it on OMAP3, although I know it's a little worse there). It should be possible to port some existing OSSv4 code with only a few small changes.

If you have rights for that code and can make it GPL for kernel compatibility then sure, why not.

 

[Exophase]

Yeah, OSSv4 is GPL. Just a matter of finding the right code to start tinkering with, maybe some people working on that can point us in a reasonable direction.

 

[fusion_power]

I don't understand much of your high level tech talk but as long as it leads to faster programs/games/emulators....

DO IT!

 

[paulguy]

Yeah, I'm all for a move to OSS4. I'd be using it on my desktop if it could use usb audio with the device I have, because when I used to use it with my SB Live!, it was fantastic compared to ALSA.

The one thing I'm worried about though is timidity, and it's ALSA MIDI device emulation. A lot of the older games like Doom and Hexen depend on this for ingame audio. Would something like this be able to work with a compatibility layer? There may also be some other oddball programs that will simply refuse to work with OSS or a compatibility layer.

 

[torpor]

Both ALSA and OSS should be gotten working properly on Pandora - imho, abandoning ALSA for OSS is really not useful, there are simply too many reasons to use ALSA in terms of apps, and there is no reason that both ALSA and OSS can't be streamlined and gotten properly working in the Pandora environment ..

 

[Spirit]

With some IRC brainstorming (everyone but me):

The ALSA software mixing seems to be the culprit.
If you feel adventous you could move the ~/.asoundrc .
But then you loose the ability to use the mixer and other bad things might happen (buffer underruns for example).

 

[Exophase]

Both ALSA and OSS should be gotten working properly on Pandora - imho, abandoning ALSA for OSS is really not useful, there are simply too many reasons to use ALSA in terms of apps, and there is no reason that both ALSA and OSS can't be streamlined and gotten properly working in the Pandora environment ..

Both can be available as options, but you can't run both simultaneously. Developers are going to need a least common denominator, and you're probably going to have more like with ALSA's OSS emulation than OSS's ALSA emulation, although we could at least have SDL, OpenAL, etc compiled which supports both.

There's been some debate about this on #openpandora - some say there are a lot of ALSA only apps, others say not a lot are using ALSA directly. I wonder what the actual situation is going to be.

 

[javaJake]

Some real nice information here on the differences: http://wiki.archlinu...isons_with_ALSA

It appears ALSA, while slower and harder to develop for, has much better hardware compatibility. A lot of the hardware it mentions I use, so I'm sticking to ALSA.

 

[torpor]

My position exactly - ALSA has the hardware support ..

So, lets get ALSA sorted, and add OSS with ALSA-emu, which anyway works pretty well already, I think.

The ALSA profile for the Pandora needs a little more consideration. What we need is a dedicated audio control panel just for the Pandora hardware - to allow switching to EXT cable audio i/o, and so on ..

 

[Polossatik]

Some real nice information here on the differences: http://wiki.archlinu...isons_with_ALSA
It appears ALSA, while slower and harder to develop for, has much better hardware compatibility. A lot of the hardware it mentions I use, so I'm sticking to ALSA.

I don't know if it's true, but that page seams to suggest only ALSA has "Support for Bluetooth audio devices. " , if so then the choice is rather clear, I think a lot of people will want to use BT headsets and so with the pandora.