PulseAudio 2.0 Is Set To Be Released Very Soon

[boast]

I haven't had any issues with PA for the longest time. But then again I also don't work at a sound studio or do anything fancy. But the linux community always has issues with the "well, it works for me so you're just a special case" in the graphics realm...

It's the same idea as: if you have a heavily compressed GIF picture and it looks like crap, will saving it as a 32-bit BMP make it look better? No, why? Because the pixels that are being displayed in the rendered gif are going to be the same ones in the BMP, just taking up more space on disk.

I'm not sure thats a good analogy for audio. Because with good digital signal processing techniques, you, for example, add an extra bit to the sampled data, and with a digital filter calculate/estimate more precisely the original source before it hits the digital-to-analog converter.

For an image, you can add an extra bit for each pixel, but you wouldn't be able to tell what the original source color was, so its useless. But for audio, if your data shows it goes from 0.5v to 0.7v, you can assume that it goes to 0.6 before reaching 0.7, and can create a smoother transition in your analog conversion, thereby making it sound better.

(note, signal processing is not my forte)

Oh, and I'm not sure why some people are confusing the sampling rate with an analog output frequency one would hear...

[ultimA]

A naive question from a PulseAudio-newbie: Why would average Joe want to install PulseAudio? IMHO, per-application volume control is the only feature that a normal user would find useful. Streaming sound to remote speakers on the network is certainly not what everybody is doing. The ability to switch devices during playback is also not very often used, you set up your system once, start palyback (music or movie or game or whatever) and listen to it without needing to shuffle the playback devices around. Mixing, sample rate conversions and a plugin-architecture for processing effects is something that ALSA, for example, also has.

So for me, and I'm pretty sure for mostly anybody, per-application volume control is the only useful thing that remains. But even though I find it potentially useful, I'm still not missing it. For what any other reason would I switch to PA?

[curaga]

You might be forced to it now or in the future, with some distros having Gnome/KDE depend on it.

[Chewi]

Mixing, sample rate conversions and a plugin-architecture for processing effects is something that ALSA, for example, also has.

Mixing is not something ALSA is very good at, particularly if surround is involved. That was the deal breaker for me but once I'd switched, I also liked what else PulseAudio had to offer.

[malkavian]

Well, how much of an audiophile are you? First of all, going beyond 96KHz only works if you're using SPDIF, and many sound cards don't let you go up to 96KHz unless you're using SPDIF. If you aren't, then you're wasting your time trying to achieve something higher. I'm almost positive that analog speakers aren't capable of handling sample rates that high. But whether they can or can't, 96KHz is really the absolute maximum anyone really needs to go, because most audio tracks are not recorded that high and even if they are, most speakers won't let you hear a difference.

That's incorrect. The sampling rate is a digital concept. An speaker doesn't have any problem handling any sound, because they receives it in analog form. If you have a film with AC3 or DTS sound, you have sound digitally encoded. You can decode it with your sound card and then send it by analog outputs to your speakers, or you can send it without decoding by spdif outputs (coaxial or optical) and then your speakers will have an internal Digital to Analog Converter (DAC) to decode it before really plating it through speakers. So spdif output use is better only to avoid interferences in the wires (but with less than 30 meters or wire, interferences are considered absurd (except ins special cases with a lot of interferences in the air)) or if the DAC of your "digital" speakers is better than the one of your sound card.

What means 96Khz? It means the digital sound have 96000 samples of sound every second. With more sampling rate you will get a more realistic analog output when decoding it again. If your source sound is a CD will use 44100hz, so playing at more that 44100hz won't give you better sound. Re-sampling it to 88200hz will (I suppose) add interpolated samplings, but afterward we will always need decode it to analog to hear it, and even the worst DAC will make these interpolations because analog means curves and not peaks (like with digital sound), so no more quality got.

Some audio sampling qualities: http://en.wikipedia.org/wiki/Sampling_rate#Audio
About bit depth: http://en.wikipedia.org/wiki/Audio_bit_depth

Just as an FYI, people can waste a lot of money on speakers/headphones with ridiculous frequency ranges, such as 10Hz-40KHz. The average human can't hear beyond 22KHz, so you could pay more for a speaker with the exact same quality as another, but the only difference is the more expensive speaker has a frequency range that goes ultrasonic.

Humans normally can hears from 20 to 20.000 hz. There are rare cases of humans hearing sounds of less or 20hz or more than 20Khz. With age we lose earing capacities since young, so maybe none of us can hear now from 20 to 20.000 and we would have loss mostly low frequencies (bass ones). And some of you maybe more, if you usually ear high volume music or sounds, you could damage your ears and ear capacity cannot be recovered. If you anytime have get out of disco/pub/bar with a treble whistle in your eras, you have damaged your ears, and that's is an alarm of damage of your body.

For example, gstreamer's audioresample plugin claims to support sample rates from 1 Hz up through 2147483647 Hz (about 2.1 GHz). 2.1 GHz is almost the frequency of an 802.11b signal (2.4 GHz) so that's definitely not perceivable to the human ear (unless you can "hear" WiFi signals..........).

You are mixing concepts. It is not the same sampling frequency and human frequency earing capabilities. I suppose that my upper explanation is enough to understand it, but if you want to question something, please do .

The only way to truly use all that extra kHz on your audio card would be to work with source audio that was originally recorded using a capture device at that sample rate.

Correct.

If you has a microphone that can accurately capture details at 192 kHz and you plug it into the capture port of your sound card, then yes, you could hear anything captured by that mic at 192 kHz of fidelity.

Incorrect. Your sound card is what has and Analog to Digital Converter (ADC, the inverse of an DAC), the microphone just get analog audio. It's your sound card (and your configuration) what needs to be able to sample the sound at 192Khz. There are USB microphones that does the sampling, but it's because they have a mini-sound card (with his ADC) inside them (probably a bad sound card and a bad ADC).

[allquixotic]

A naive question from a PulseAudio-newbie: Why would average Joe want to install PulseAudio? IMHO, per-application volume control is the only feature that a normal user would find useful. Streaming sound to remote speakers on the network is certainly not what everybody is doing. The ability to switch devices during playback is also not very often used, you set up your system once, start palyback (music or movie or game or whatever) and listen to it without needing to shuffle the playback devices around. Mixing, sample rate conversions and a plugin-architecture for processing effects is something that ALSA, for example, also has.

So for me, and I'm pretty sure for mostly anybody, per-application volume control is the only useful thing that remains. But even though I find it potentially useful, I'm still not missing it. For what any other reason would I switch to PA?

Several things:

1. Software mixing, since most people don't have a hardware mixing card. ALSA doesn't have "proper" software mixing: it has dmix, but that does naive saturation sampling, which basically means adding up the samples from each stream, which can cause pretty nasty results (bad audio quality). You have to remember that software mixing is much more than adding sample values together; it also has to take into account sample format conversion and latency.

2. Timer-based scheduling in the PA core. ALSA itself doesn't do timer-based scheduling; it provides a function which allows you to turn off the processing of hardware sound card interrupts, but it doesn't have any mechanism to replace those periodic interrupts with CPU-based waiting. This is what PA does. Since you indicated you're an end-user, I'll spare you the gory details of why this is good. The basic idea is that (1) you are less likely to have sound dropping out; (2) you can have different programs playing back at different latencies, which saves power (and CPU time) for the apps that don't need low latency, while apps that do need low latency can get it; and (3) sound is less likely to drop out during heavy I/O, since interrupts coming from a PCI sound card can often get held up within the internals of the CPU, especially on older machines, which leads to interrupt jitter and can cause crackling or other bad effects in the audio.

3. Buffer re-writing (rewinding) in the PA core. The main advantages of this one are that volume adjustments happen more quickly, and if your audio *does* occasionally drop out, PA can try to cope with the dropout and minimize the impact of it.

4. Due to the way PA is wired into the high priority permissions system, a regular user can obtain "soft realtime" permissions through PolicyKit for PA, which means that your audio I/O will take higher priority over things like video, or that greedy daemon that decides it wants to eat 100% CPU. I had a "speech-dispatcher" daemon erroneously eating 100% CPU recently, but because I'm using PA, I didn't even notice there was a problem until I started to see slight mouse lags, slower compiles, etc. But my audio kept on playing without any dropouts, despite the fact that the PA daemon and the media player were eating several percentage points of CPU time.

5. You can do things with the GUI configuration tools instead of editing config files. I know Alsa has a few config tools, but let's face it, they suck. PA's GUI tools are rock-solid, especially gnome-sound-applet in Gnome3. You can do things like select that USB headset you just plugged in with the click of a mouse button and without restarting any apps. Not so easy for ALSA. # nano /etc/asound.conf ..... type some shit... realize you made a syntax error.... go back, do it again, test it.. restart apps... yeah, no thanks.


You would intuitively think that, since PA sits "on top of" ALSA, that it's going to at least add some kind of inefficiency, right? Well, I disagree. I think that with the timer-based scheduling and the other features I discussed, it's actually quite a lot more efficient than ALSA. For example, imagine this scenario.

You have a Skype conversation open. Since this is a telephony app, you want the latency low, or your conversation will be weird (you'll be interrupting each other, etc). So Skype requests a very low latency; let's be ridiculous and say it wants 6 ms of latency. Fine. Assuming your system is idle enough to handle that frequent of an interrupt, everything should be happy.

Now you start playing a Flash video because someone linked it to you in chat. Since this is a non-interactive playback app, the size of the buffer (i.e. the latency) is not going to affect your experience at all, except that bigger buffers require less frequent interrupts which lowers CPU time. So what PulseAudio will do, usually, is it'll allocate a huge 2 second buffer (or even more) and fill it with audio. PulseAudio itself will have to keep waking up to service Skype's demanding 6 ms schedule, but it won't have to wake up the thread that reads audio from Flash, nor will Flash itself have to do anything audio related each time it wakes up. So your potential CPU usage in the Flash process just went from about 40% on a Core i7 (my own system) to about 0.1%, because it's getting 2000 ms of latency instead of 6 ms. But you don't care about the high latency, because you're just listening to a video. You can also think of it this way: if the entire video content of a Flash movie downloads and buffers up the entire 10 minute video in 5 seconds, does that negatively affect your experience? No. The key thing to realize here is that all of the content is known in advance with videos and music, whereas with VoIP, the content is dynamically changing constantly, so you can't queue up a huge amount of data and expect real-time interactivity. Even if you are streaming media from a network, such as a Shoutcast stream, you can still buffer up to 30 seconds of the audio into the shoutcast client (and they usually do this, sacrificing latency between the client and the shoutcast server) and then buffer up 2 seconds of audio between the shoutcast client and PulseAudio.

So what a high latency stream does, is it reduces the amount of back and forth communication between pulseaudio and the client, and (to a lesser extent) between pulseaudio and ALSA. But since you can have latencies in PA clients which are greater than the maximum amount of data that ALSA can buffer at a time (it's hardware-dependent IIRC), you can actually buffer up several minutes of audio in PA if you wanted, and PA would just fill ALSA's maximum-latency buffer, however big that is, without asking anything of your client until its own buffer is almost empty.

So what did we learn, class?

1. If you have a device that runs on battery power, and you want to listen to audio while on batteries, PA's timer-based scheduling is a huge win for power savings.

2. If you frequently start applications whose use-case-based optimal latency is widely variable (e.g. 6 ms for Skype, 2000 ms for static content), PA's timer-based scheduling is a huge win for CPU time savings.

3. If you have older hardware that has difficulty multi-tasking without dropping your audio, PA's timer-based scheduling and buffer rewinding is a huge win for playback stability.

4. If you ever use more than one sound card on your system (a USB Headset counts as "a sound card"), PA's GUI tools are a huge win for ease of system configuration.

5. All those "special" use cases you cited in your post, while I don't think they're very uncommon, are nonetheless possible with PA while impossible or prohibitively difficult with ALSA. So why wouldn't you want that capability?

If you're all about simplicity and not having a flexible system that's ready to do what you want (even in the rare case that you might actually want to do something interesting with audio), run Minix or Hurd. The advanced free desktop with a sugar coating of features will be here waiting for you when you come back screaming that Minix doesn't do software mixing at all.

I'll conclude by saying that there is a very good reason why PA is the default on all the premiere distributions. It unfortunately takes a small amount of integration and manual configuration to get it running properly if you are installing PA from source code on a distro that otherwise doesn't support PA. But if you use a distro with an actually-good implementation of PA (such as recent Ubuntu, Fedora or OpenSUSE), you don't have to do anything. You just turn on your computer, start playing audio, and you don't even notice PA sitting in the background, quietly fighting system resources to deliver you reliable, high quality audio, sample after sample. If PA is invisible to the user, it has accomplished its goal.

[aceman]

Thanks, this is what I was asking for.

[malkavian]

Great answer allquixotic. I will give a try again to PA in my Debian testing. In the past, it was buggy.

[GreatEmerald]

Interesting, but I still see most of those as special cases. If you're running a pretty fast stationary PC, points 1-3 are irrelevant. Point 4 is interesting - last time I used PA, there were no GUI tools to begin with. However, since I'm a KDE user, using ALSA is not bad in that regard at all. I just go to system options and press a few arrows to rearrange things. Per-application audio control does sound very nice, however.

Hmm, according to PulseAudio wiki, KDE now has pretty good integration, something that was completely absent last time I tried it. And apparently some extra packages are needed to get the GUI tools. So that's good to know. Still, I don't see real reasons in my case to switch to PA from ALSA right now. As it stands, I'd rather go by "If I need extra sound management features, install PA; else, stick with ALSA". On certain systems it's "If out-of-the-box ALSA doesn't work, use PA; if out-of-the-box PA doesn't work, use ALSA".

[allquixotic]

Interesting, but I still see most of those as special cases. If you're running a pretty fast stationary PC, points 1-3 are irrelevant. Point 4 is interesting - last time I used PA, there were no GUI tools to begin with. However, since I'm a KDE user, using ALSA is not bad in that regard at all. I just go to system options and press a few arrows to rearrange things. Per-application audio control does sound very nice, however.

Hmm, according to PulseAudio wiki, KDE now has pretty good integration, something that was completely absent last time I tried it. And apparently some extra packages are needed to get the GUI tools. So that's good to know. Still, I don't see real reasons in my case to switch to PA from ALSA right now. As it stands, I'd rather go by "If I need extra sound management features, install PA; else, stick with ALSA". On certain systems it's "If out-of-the-box ALSA doesn't work, use PA; if out-of-the-box PA doesn't work, use ALSA".

It shouldn't even be a question of whether to use PA, unless you're using a Linux distro that doesn't ship PA by default. And if that is the case, I'd say switch distros, because You're Doing It Wrong (tm). Sorry, but distros that don't ship PA are basically the same as distros that ship the old pre-X.Org "Xfree86" server, or OSS instead of ALSA. These people are the extreme minority.

The only reason not to use PA is if you have sound hardware where it works fine with ALSA but not with PA. Thanks to a plethora of bug fixes in the ALSA libs and kernel, any kernel since about 2.6.30 or later should be able to drive PA as well as it drives "native" ALSA. I'd argue that the existence of sound hardware that falls into this category is a much smaller minority than the subset of users who would be interested in one or more of the useful features of PA.

Besides, who doesn't like CPU savings? Who likes audio dropping out when they are copying a lot of files? Are these really such niche needs that it's not worth 10 to 20 MB of memory (see the end of this post if you think PA uses more than that)?

I can see JACK as being a potential differentiator because it offers even lower latency and even stronger realtime guarantees than PA (assuming you have the right kernel bits compiled). But JACK has its own advantages and disadvantages. Compared to raw ALSA, though, pulseaudio is nothing but upside, with no downsides.

P.S. -- Those of you who think PA uses a lot of memory should look at the shared memory files that dmix uses for software mixing. Those aren't visible in "top", but they consume resources nonetheless. Also make sure that before you talk about PulseAudio's memory usage that you actually understand how virtual memory works under Linux, and make sure you can precisely explain the difference between virtual memory, resident memory and shared memory ("VIRT", "RES" and "SHR" in top). If you don't know PRECISELY what these are, you really have no ground to stand on when talking about PA's memory usage.