| |||||||||||||
GStreamer: Past, present, and futureGStreamer: Past, present, and futurePosted Oct 27, 2010 17:10 UTC (Wed) by gmaxwell (subscriber, #30048)In reply to: GStreamer: Past, present, and future by elanthis Parent article: GStreamer: Past, present, and future
> You're slightly over-estimating the power of many mobile CPUs.
More than slightly. Pulseaudio's mixing/filtering stuff is using tens of percent of CPU on N900. It's more computationally expensive than the whole vorbis decoder. It's problematic (e.g. for webm playback in a browser).
> you'd pretty much be forced to work with 64-bit floating point
I'm pretty sure thats BS. Outside of some numerically unstable filtering internals there is no reason to have that much precision in any general audio pipeline.
But even 32-bit float is more or less a non-starter in some existing environments.
(Log in to post comments)
GStreamer: Past, present, and future Posted Oct 27, 2010 17:45 UTC (Wed) by alankila (subscriber, #47141) [Link]
Maybe your pulseaudio is resampling, or maybe it spends 90 % of time in gettimeofday(). It'd be a good idea to acquire an oprofile trace to figure out where it is hurting so much. Also, be sure to fix CPU speed to some known frequency, otherwise percentual usage values are a very poor metric for measuring relative performance.
I know that mobile systems may require the use of integer arithmetics, although I am hoping that floating point capability will get added to every CPU in time. Software emulation of floating point exists, but in practice software float is too wasteful to be acceptable. I did some quick testing on a HTC Hero and got the result that software emulated float took about 5x the time of similar integer code.
My practical experience suggests that the sort of things gstreamer needs to do (dithering, scaling, mixing, copying) take insignificant time compared to any other work that is also ongoing. That would also include decoding any codec.
GStreamer: Past, present, and future Posted Oct 28, 2010 20:22 UTC (Thu) by oak (subscriber, #2786) [Link]
When playing just music on N900, the dynamic frequency scaling scales the CPU speed down to 250MHz (easiest to see from /proc/cpuinfo Bogomips value changes). Pulseaudio needs to do on N900 more complex/heavier stuff than normally on desktop (sound volume increase, speaker protection...).
Oprofile tells that about third of CPU goes to pulseaudio internal workings, rest is sound data manipulation which is accelerated with NEON SIMD instructions (as you can see by objdump'ing the related libraries code).
N900 uses TI Omap3 (ARM v7) i.e. it has HW floating point support. Sound HW is AFAIK 48kHz natively.
GStreamer: Past, present, and future Posted Oct 29, 2010 0:35 UTC (Fri) by Spudd86 (guest, #51683) [Link]
Then pulse doing resampling seems pretty likely since so much audio is 44.1KHz
GStreamer: Past, present, and future Posted Oct 27, 2010 17:49 UTC (Wed) by baldridgeec (guest, #55283) [Link]
Ever done live mixdowns of 16-channel audio with separate effects pipelines running per channel? Some people do real audio work with Linux, and it is quite capable if set up properly.
The issues you're talking about are somewhat annoying for desktop audio, but that's not the only use case that has to be considered. Pulseaudio has been getting better - I like that it knows enough to get out of the way of JACK-enabled applications now.
GStreamer: Past, present, and future Posted Oct 27, 2010 18:09 UTC (Wed) by drag (subscriber, #31333) [Link]
Another example is if your using it for something like VoIP.
If you want to be able to do voicemail, conferences, transfer phones, put people on hold, work with multiple protocols, hook into a T1 or POTS and all that then your VoIP system is going to require a backend that can handle manipulating audio and transcoding between different formats.
Sure most of the audio formats used in VoIP are uncomplicated, to say the least, but if your handling a call center with a 100 phones with the multiple voice bridges and all that stuff then it adds up pretty quick.
Then another issue is the sound cards itself. Sounds cards only support certain audio formats and your going to have to be able to support a multitude if your going have a efficient way of outputting to the real world.
|
|||||||||||||