Pulseaudio should switch sample rates when possible

[Florob]

I'm using pulseaudio as currently in Ubuntu Hardy Heron. CPU usage was very high (at least 6% often 20+% on my CPU which makes music skip etc. and it even does using speex-float-0). After some research I found out that this is due to resampling. My soundcard (M-Audio Audiophile 2496) seems to support using different sample rates in hardware which you can switch using e.g. alsamixer. ALSA always switched to the correct sample rate automatically and never had to do any resampling it seems (or if it did at least it wasn't THAT CPU intensive). As pulseaudio seems to be using only one fixed sample rate per soundcard this benefit of not having to do resampling in software is gone. If possible this should be changed.

[lennart]

Sorry, this won't work: what happens if you have more than two streams connected with different sampling rates? Reopen the device which causes discontinuities?

Modern sound cards don't support changeable sampling rates anymore. Digital resampling is how things should be done. That's how Vista does it and MacOS too.

If you feel that PA takes too much CPU time for resampling: the reason for this is that in the traditional model the client app did the resampling, and thus the amount of CPU necessary for the resampling wasn't clearly visible in top. Since PA does this now it suddenly becomes visible, however the work was just moved to another process.

Also, the linear resamplers mplayer, gst and even alsa used and uses are really really crappy. They take little CPU but sound like shit. In PA we have a proper resampler which sounds good but has the side effect of taking up more CPU time.

[Florob]

Well, from my point of view you have to look at it this way: a) If you play 2 sound samples and none has the correct sampling rate for your soundcard, why do resampling twice instead of changing the soundcards sampling rate? Because the uncool kids do it doesn't really sound like good reasoning... b) What sounds worth, linear resamplers or stuttering music?

[Letto]

Modern sound cards don't support changeable sampling rates anymore. Digital resampling is how things should be done. That's how Vista does it and MacOS too.

This is not true. The Delta Audiophile 2496 is quite popular. I've seen it recomended as a high quality sound card in a couple of places and I think a fair number of linux users have those. For example the wiki of alsa and gentoo are full of example .asoundrc files for those cards. Saying that you won't support samplerate switching is saying that you won't support those cards. That would be a shame. Please reconsider this, especially since alsa worked quite reliably in this regard.

For the record PA seems to only transmit 44.1k even when i lock the clock at 96k. That is clearly wrong. Alsa seems to even have a special control program for those card called envy24control. That has to prove that they're popular or somethin. :)

[lennart]

Dude, we ask ALSA for a 44100hz by default, and also ask it to not give us anything that is not native to the hardware. Then, we take whatever ALSA gives us, which might be different from 44100hz. Could be 48khz or whatever.

What I was referring to is that we won't do on-the-fly sample rate switching. You are always welcome to configure PA via default-sample-rate= option in daemon.conf to a different sampling rate.

But again: PA will *not* default to any "artificial" sampling rate. We try our best to convince ALSA to hand us only *native* sampling rates.

Florob: Resampling won't cause you stuttering music. Not on any hardware that is newer than 10 years. However, if we'd switch sampling rates all the times when a new client connects and requests a different rate and have to close and reopen the audio device for that then you would certainly hear that as nasty drop outs. Just think of this case: you play two streams at the same time. First you start one with 8khz sampling rate. When it is half way through you start one at 44khz. In the world you are requesting we'd first open the audio device in 8khz and as soon as the second stream starts to close it and reopen it in 44khz. You will certainly hear that, the first stream will be interrupted for a short time! So in short: what you are requesting will cause bad sound quality.

In summary, what you guys are requesting doesn't make sense.

In PA 0.9.11 we will probably ship an SSE optimized version of the Speex resampler. Then you probably won't be able to even notice the CPU load. I'll then also change the default sampling rate to 48khz, which is what dmix did already.

[Letto]

But this is wath alsa already does and in the real world it does not cause any problem. Why can't you just initialize the first stream at it's sampling rate and resample the others to that rate. Alsa doesn't even do this, it just initializes the card at the first sampling rate and then if you start something else that is not the same rate it doesn't even work. I don't think it really causes trouble in practice, at least nobody seems to complain about it.

Thanks for the info on the default-sample-rate option.

[lennart]

Letto: uh? ALSA dmix defaults to 48khz. You can configure that in asoundrc. It doesn't take into account in any way what potential clients might be asking for.

And what you suggest doesn't work. What if the first stream that is played is an 8khz event sound and then your are stuck with 8khz for the rest of your session?

Really, it doesn't make sense.

[Letto]

Alsa doesn't resample anything for me, if i configue .asoundrc right i don't need to specify any sampling rate.

here's wath i have in .asoundrc

pcm.!default {

type plug slave ice1712

}

pcm_slave.ice1712 {

pcm "hw:0,0"

}

this isn't anything complicated, it just makes alsa properly recognize my sound card.

No, you're not stuck at any sampling rate, if there is no stream playing you can set any sampling rate you want when the next one starts. It works even when switching tracks.

And really irl you don't have 8khz sampling rates , you mainly have 44.1k, 48k and maby 96k . And you can have it upsample anything that is lower tahn 44.1k if that is your concern.

[lennart]

Letto: But the fragment you posted doesn't do any mixing. no dmix. And even if your specific hw should have hw mixing, it will have that only for a very limited number of concurrent streams. So, it's not really usable. Sorry.

An example: we got event sounds attached to our buttons, at 8000Khz. Someone clicks on the "play" button of our media player. Wants to play his ultra high quality SuperAudioCD at 96000khz. What happens now is that because the event sound was started first the audio devices is being fixed to 44100hz and then the entire CD is stream with 441100hz. Oh my. Not what we want.

Again, what you suggest is impractical. Doesn't work. It'd be a hack. And for what? A tiny bit of CPU usage less? You won't be able to claim a any difference in quality. Also the more modern sound chips usually are fixed to a single frequency anyway. So the whole discussion is kind of pointless.

The right fix to your problem is to optimize the resampler for SSE. Not adding any kludges to change the hw parameters around all the time. Any you know what? Those SSE optimizations have already been posted. It's just a matter of integrating them.

[Florob]

Replying to lennart:

Florob: Resampling won't cause you stuttering music. Not on any hardware that is newer than 10 years. However, if we'd switch sampling rates all the times when a new client connects and requests a different rate and have to close and reopen the audio device for that then you would certainly hear that as nasty drop outs. Just think of this case: you play two streams at the same time. First you start one with 8khz sampling rate. When it is half way through you start one at 44khz. In the world you are requesting we'd first open the audio device in 8khz and as soon as the second stream starts to close it and reopen it in 44khz. You will certainly hear that, the first stream will be interrupted for a short time! So in short: what you are requesting will cause bad sound quality.

I don't know if you realize how bad an impression you make saying the problem your users are having does not exist.

The fact is. No pulseaudio, everything is fine. Pulseaudio with one or multiple streams at default sample rate, fine. Pulseaudio with one stream not at default sample rate, works with relatively high CPU usage. Pulseaudio with two streams not at default sample rate, epic fail. And my hardware is newer then 10 years...

Maybe the SSE change will help but as a matter of fact Pulsaudio is useless for me right now. If you say it's not resampling you are welcome to suggest what else is causing this trouble.

I short: I don't really tell you how to write your software and you know way more about Linux audio I guess, but please don't tell me I'm imagining things, be helpfull instead. Please.