Recently switched to PulseAudio after quite a bit of time without it. And, well, I had some problems. One is that tracks that use non-standard sampling rates (32k, for instance) would have crackling sound. Setting PA to use the interrupt method fixed it; on the other hand, that completely broke Wine (it worked fine initially, but after setting that all sound was corrupted in a horrible, horrible way). So right now I reverted back to the tickrate method, but enabled remixing, and it gives me a lot less crackling (like a crack every 10 seconds), which is nearly as good as it was with ALSA only.
The best thing I like about it is Veromix. It's just incredibly simple and incredibly useful. One place to change the volume of each application, each recording device, and even control Amarok or other players. It basically makes pavuctl obsolete. Not to mention KMix (with which it had conflicts, I think).
I still have recording related problems (audio gets desynced), but I can't tell if it's related to PulseAudio or just the recording software...
So overall, it's quite good now. Version 2.0 is probably going to be even better (still using 1.2 here).
I've tried it for one month. There are a lot of workarounds needed to get every application working. And when you look into the ubuntu repositorys, what they have done to gt all this stuff working .... no thanks.
Alright, so to me this is an EXTREMELY unusual case. I use tens of open source and even some proprietary applications on Linux with PulseAudio and I haven't had any sound problems for at least a year or more (granted that I always run the latest stable of either Ubuntu, Fedora or openSUSE, so I usually have the latest stable build of PulseAudio and maybe some distros patches as well).
Maybe what you could do is list the applications that don't work well with PulseAudio. Can you do that?
If we want to try and improve the situation, we can ask the PulseAudio developers (or the developers of the apps that need workarounds) to try and resolve it so that it works out of the box.
Rather than complain about it, let's contribute bug reports and I'm sure Colin Guthrie or Arun Raghavan or Tanu Kaskinen would be more than happy to give advice.
alternate sample rates
What is this and why should I care? What is it good for?
It means that PA will switch sample rate to match the streams better. The old way was to open the device with one samplerate (my guess would be to match the first stream),
,all streams with different sample rates had to be resampled.
i.e.: you started to play 44100 sound, device was configured to use 44100 and every other playback was resampled to that rate.
PA2 will switch device sample rate configuration dynamically to avoid as much resampling as possible (if your device supports such switch),
or make the resampling more efficient (faster, less sound changes), i.e reampling from 88.2khz to 44.1khz is faster and produces better quality than 96khz to 44.1khz
it means less resampling therefore less CPU usage and better sound
Originally Posted by uid313
This means if you plug in your headphones then audio stops coming from the speakers and start coming from the headphones.
If you unplug your headphones, then audio resumes from the speakers.
AFAIK swithing ouput when headphones are pluged is done by alsa drivers,
this change should make PA aware of this change so that it can react (like chage volume levels).
on my laptop the build-in speakers have really low volume, so when I use headphones the sound will blow my head off if I don't lower the volume first
OK. My Wine locks onto ALSA using a winealsa.drv, other words I no longer get an option to select OSS.
If I recall correctly, recent release of wine should "lock on" to OpenAL, which means that your audio path will go wine -> OpenAL-Soft -> PulseAudio (native). This path was heavily tested and works extremely well. What is your wine version?
Originally Posted by e8hffff
Why is PulseAudio chosen over OSS for Ubuntu-Kubuntu?
There are two different types of oss... well, actually three:
1. "In-kernel" OSSv3 Legacy... this is "mainline" OSS that hasn't been maintained for years, I think they might've even removed it from the kernel entirely?! This has TERRIBLE hardware support, TONS of bugs and generally is not viable. No one should use it.
2. OSS Proxy (a.k.a. osspd), which is a brand new solution. The audio path goes: OSS application -> /dev/dsp character device -> in-kernel "CUSE" (Character Device In Userspace) kernel module -> back to userspace "osspd" daemon -> PulseAudio daemon. Lot of audio routing / copying, but it's very flexible and fully supports all of PulseAudio's features for OSS applications. Highly recommended if you have apps that need to use OSS. And the CPU usage all considered is not all that bad, although latency is not suitable for professional audio applications like DJing or mastering. 100% fine for desktop usage and gaming
3. OSSv4 from 4-Front Technologies, which is a semi-old but still maintained (?) implementation of OSSv4 for Linux. Since this doesn't use ALSA at all, the hardware driver support is at the mercy of the one guy who writes and maintains OSSv4. I have been trying OSSv4 with my on-board Intel HDA sound every couple of months, and for three years now (and counting), the kernel hard-locks (panics) when loading the kernel module for my Intel HDA soundcard. You may not have the same results, but I certainly wouldn't want something that bad on my system. Also, when I try any of the three modes for my USB Audio Headset, it does one of three things: hard-locks the kernel, plays awful (LOUD, ear-busting) static, or plays the sound at an extremely high rate (sounds like chipmunks) for about 3 seconds and then segfaults the user-space application. Lovely. Also, OSSv4 doesn't always compile cleanly with the latest upstream kernel releases, just like any out-of-tree driver.
Originally Posted by e8hffff
What is the PulseAudio vs OSS4 difference?
PulseAudio works; OSSv4 crashes your kernel.
No, in all seriousness: PulseAudio primarily likes to use ALSA, which has much better (more stable and functional) drivers for almost all sound cards in existence (Audigy is infamously one of the exceptions). PulseAudio uses timer-based scheduling, which means that it can control exactly when to wake up to feed more samples to the soundcard, which saves energy and helps PulseAudio adjust to the latency demands of applications: if an app demands low latency, it will get it; if an app demands high latency, it will get it. And the cool thing is, if all the running apps only need high latency, PA can go to sleep for long periods of time, letting the CPU rest in between latency periods. If our open source graphics drivers could be this smart, then desktop Linux would be far and away the most efficient operating system for battery-powered laptop usage! We definitely have it nailed down with the audio stack, so now we just need to get it going on the graphics side, which is a whole separate topic.
PulseAudio also does network transparency if you need that. It also does bluetooth if you need that. It also does echo cancellation in your microphone/speakers if you need that. It also does all kinds of fancy resampling and channel remapping and moving playing audio applications between sound cards without stopping playback if you need that. It also controls all volumes with one nice slider (and still lets you turn down your music so you can hear people talking in another stream) if you like that. It also can play back to OSSv4 (although not very efficiently; it doesn't support timer-based scheduling with OSSv4) if you absolutely insist on using that.
So, bottom line, PulseAudio is the most robust component of the audio stack, even more robust than ALSA... but it has a symbiotic relationship with ALSA, because PulseAudio won't be "at its best" (efficient and working well) unless it's playing back to ALSA. So it depends on and needs ALSA for the best results, but you don't want to just use ALSA, any more than you'd want to just code all of your applications with raw libX11... this is why we have GTK and Qt. PulseAudio is GTK or Qt for audio.