PulseAudio 0.9.20 Arrives With Fixes

[BlackStar]

Are you so sure about?

Yes.

AFAIK, if a card is capable of 48 kHz, is also able of converting a 44 kHz stream, or at least it is possible to program the chip to accept such a stream. If the chip has fixed sampling rate, then it will care itself about resampling...

Realtek chips only support one hardware voice, so you have to pick a rate and resample everything else to match. Mixing must be done in software.

Sure it doesn't prove anything, but gives and order of magnitude of the computational time required.

You reported CPU usage of 3-4%. You also reported that decoding a 80Kbps ogg file requires 2-3% of the CPU (virtualized, so let's imagine for a moment that we're running on raw hardware but decoding a 192Kbps file instead - results should be close enough). This puts an upper limit to pulse CPU usage of about 0--1%.

What order of magnitude does 0-1% give you?

[blackshard]

Sorry, but you have no idea what you are talking about.

Are you so sure about?

1. Resampling can be more CPU-intensive than decoding ogg, if you use a high quality algorithm. Pulse's default is a good trade-off between quality and speed that works great for most applications. If you are not happy, modify that.

2. Software mixing (hence resampling) is absolutely necessary on 99.99% of all computers out there. How else are you supposed to listen to your 44KHz ogg using your 48KHz realtek chip?

Sure, of course resampling can be cpu intensive. You can use polyphase filters, spline interpolation or other nice resampling filters. But do we really need it?
AFAIK, if a card is capable of 48 kHz, is also able of converting a 44 kHz stream, or at least it is possible to program the chip to accept such a stream. If the chip has fixed sampling rate, then it will care itself about resampling...

Also, resampling 1 (one) stream in software even with a nice resampling filter (spline for me is already nice, fast and with sufficient high quality) will never require 3-4% of cpu time on a 2.5 Ghz machine (unless you wrote it in intrepreted Basic language), as misiu_mp reported.

It could be a configuration problem, I don't exclude this, but then, probably, default configuration is wrong.

3. How did you come up with this 3-4% number? By playing back an ogg file? If so, do you understand why this is completely invalid?

Sure it doesn't prove anything, but gives and order of magnitude of the computational time required.

[misiu_mp]

I'm actually surprised how little power it uses. It did consume a lot of cycles in the past, but these days that doesn't seem to be true any longer. I suppose that it all depends on your setup, and what features you're using though. But on a plain setup it seems to hardly impact performance.

Your numbers are a really good sign.

I am using a standard fedora 11 setup with version 0.9.15 of PA. Recently phoronix reported 0.9.20 was released (fedora 12 will ship with it). Could be much have changed. Maybe fedora 12 brings the same performance improvements as Karmic Koala (or maybe Keramic does not resample and fedora does). What version of PA do you have?

You think the sound card hardware matters? Can pulse use better hardware to accelerate some operations?

[BlackStar]

I had Duron 850Mhz and it was also about 10%, so unacceptable for me, but some people says it can be problem with Pulse Audio configuration.

Most distros ship with configurations optimized for current hardware, the Duron is obsolete three times over by now (great chip btw, I have one too. Watt-guzzler, though).

Anyway, this is easy to fix if you spend a couple of minutes reading the documentation - pulse is very configurable. Just make sure you are using the latest version (pulse has progressively gotten faster).

[BlackStar]

Yet, decoding vorbis is definitely a hard task that requires some amount of FPU code to be executed, data moving, etc...
Is pulseaudio doing something comparable as decoding a vorbis stream? In my opinion, it is not.
In a default configuration it may resample (is it really needed? Why resampling all the time when 99% of people doesn't need it?), may apply a volume amplification and do some routing. Does this justifies 3-4% of cpu time on a 2.5 Ghz machine? Don't think so.

Sorry, but you have no idea what you are talking about.

1. Resampling can be more CPU-intensive than decoding ogg, if you use a high quality algorithm. Pulse's default is a good trade-off between quality and speed that works great for most applications. If you are not happy, modify that.

2. Software mixing (hence resampling) is absolutely necessary on 99.99% of all computers out there. How else are you supposed to listen to your 44KHz ogg using your 48KHz realtek chip?

3. How did you come up with this 3-4% number? By playing back an ogg file? If so, do you understand why this is completely invalid?

[kraftman]

How come my 2.5GHz Core2s need to give up to 10% of their awesome powa to pulseaudio then? How much would that translate to on a 1GHz PIII?

I had Duron 850Mhz and it was also about 10%, so unacceptable for me, but some people says it can be problem with Pulse Audio configuration.

@Blackshard

In a more general point of view (IMHO) these are one of the most common performance regression reasons (code not well optimized, introduction of unwanted features enabled by default, etc...) that phoronix has pointed out on a recent article about performance regression of newer linux kernels.

Actually which regressions? Afaik they test Ubuntu kernels which probably have some patches, mainline kernels can be free of some regressions. Btw. what reasons? It doesn't justify Pulse Audio in my opinion. However, it can be just its configuration problem.

[blackshard]

Ah, I realized pulse consumes 9% of the C2Duo 2.5GHz (6MB) but running at 800MHz! Forcing it to 2.5GHz make pulse go down to 3-4% in cpu use.
I wonder how much faster is my cpu @ 800MHz than an arm @ 800Mhz. It seems quite clear though that there is indeed enough cycles for pulse at this level. Still, if it will run at ~20% of an arm cpu it will consume way too much power for just playing an mp3. Or would it be too much? If remember correctly I could play mp3 on 700MHz Athlon with much less years ago.
Does somebody know what could the cycle cost of an optimal solution be? This way we could measure the actual efficiency of sound systems and compare them?

ARM and x86 are not directly comparable. It is a different architecture with a different instruction set.
BTW, consuming 3-4% of cpu on a 2.5 Ghz modern processor IMHO is still a huge waste of power.
For comparison, I have and AMD Turion 2.1 Ghz processor, and decoding a vorbis 80kbps stream requires 2-3% of cpu time under virtualization. Yet, decoding vorbis is definitely a hard task that requires some amount of FPU code to be executed, data moving, etc...
Is pulseaudio doing something comparable as decoding a vorbis stream? In my opinion, it is not.
In a default configuration it may resample (is it really needed? Why resampling all the time when 99% of people doesn't need it?), may apply a volume amplification and do some routing. Does this justifies 3-4% of cpu time on a 2.5 Ghz machine? Don't think so.

In a more general point of view (IMHO) these are one of the most common performance regression reasons (code not well optimized, introduction of unwanted features enabled by default, etc...) that phoronix has pointed out on a recent article about performance regression of newer linux kernels.

[benmoran]

I just did a test out of curiosity. I'm running Karmic Koala with no changes to the audio stack. I started up 3 programs: Banshee, Rhythmbox, and played a Flash video in Firefox. CPU is an AMD Turion TL-58 (1.9ghz dual core), laptop is a Dell Inspiron 1501.

With the CPU locked at 800mhz, PulseAudio used between 2~6% cpu cycles, averaging 4%.
With the CPU left on-demand (stayed around 1.6ghz), PulseAudio used between 0~2% cpu cycles, staying at 0% most of the time.

Not bad for 3 programs running at once. I tried the second test with sound re-routed to my Bluetooth headset, and it bumped the % up to a constant 2%, with occasional jumps to 6~8% when the CPU frequency lowered itself to 800mhz.

I'm actually surprised how little power it uses. It did consume a lot of cycles in the past, but these days that doesn't seem to be true any longer. I suppose that it all depends on your setup, and what features you're using though. But on a plain setup it seems to hardly impact performance.

[val-gaav]

Well I'm enough pissed that Xorg takes 5%-10% of my CPU for just being there. BTW Juk takes just 2-4% of CPU for playing an mp3 here... and that's on 800Mhz scalled turion x2 cpu.

[misiu_mp]

Ah, I realized pulse consumes 9% of the C2Duo 2.5GHz (6MB) but running at 800MHz! Forcing it to 2.5GHz make pulse go down to 3-4% in cpu use.
I wonder how much faster is my cpu @ 800MHz than an arm @ 800Mhz. It seems quite clear though that there is indeed enough cycles for pulse at this level. Still, if it will run at ~20% of an arm cpu it will consume way too much power for just playing an mp3. Or would it be too much? If remember correctly I could play mp3 on 700MHz Athlon with much less years ago.
Does somebody know what could the cycle cost of an optimal solution be? This way we could measure the actual efficiency of sound systems and compare them?