Amongst other things, I think they're finally reverting the half-baked patch in 4.0 that broke various resamplers. Wonder which of the changes will cause me problems this time around...
Personally Pulseaudio has always been "that thing that fixes all those problems I never had with ALSA." I realize there is more to it than that but I have never really understood what pulseaudio does for me a casual sound user? Sound on my computer is exclusively produced by mpd, vlc and flashplugin-nonfree and I do not remember the last time I used a microphone on a linux machine.[1] I have browsed through the docs a couple of times but I have never figured out why, let alone how, I would want to change anything.
The only thing about Pulseaudio that I am confident of is that it is less overkill than jackd for my use cases. What am I missing?
[1]: I guess I have used the microphone a couple of times but it was always because I thought I would try Skype again. But this always resulted in a ton of wasted time with 32bit libraries and an avalanche of qt dependencies. I would get skype to work but I used it so rarely that by the time I needed it again I had to go through all the nonsense all over again.
I think some of the virtualization of devices and device sharing works a little better with Pulse. I think the UI is little slicker for some of this. I still use ALSA for post-processing on my media center, and I have used Jack for music applications. In general Linux audio is a clusterfuck, but once you dig through it all it is hard to criticize without advocating making an even bigger mess.
Printing? If you think CUPS is bad I take it you never had to get lpd and some crappy HP inkjet to work. What does CUPS not do for you? Last time I looked it even does avahi by default. Sure having a million foomatic filters installed is a waste of space but I have never come across a printer that was not covered by the base set of filters.
I don't think CUPS is bad at all: Printing is such a craptacular nightmare that CUPS is one of the least worst solutions around.
It speaks volumes that Apple chucked their extant printing code in the bin and switched to CUPS as their printing backend, because CUPS was better than any of the alternatives available to them.
I think a lot of this is just a difference in workflow. I don't think I have ever intentionally had two programs playing sound at the same time. NoScript/RequestPolicy/Adblock essentially mute flashplugin-nonfree for me. The only places flash runs are places where I want the sound.
The headphones do not matter, USB headphones were picked as examples because they're 'sound cards' usually. You could substitute 'moving from HDMI output to your speakers' or something. It's just about the ability of migrating running audio between devices, something I'm regularly doing.
Sound at the same time: Happens regularly for me. I'm listening to music and some IM client runs. I could mute that client (in the client itself) or .. reduce the volume of that one application (in PA). NoScript and RequestPolicy were too much of a hassle to me in the past tbh. I regularly end up with a braindead/moronic website playing some random video. Muting flash while I look for the offending tab makes me a much saner person.
Were the headphones a contrived example? I was just curious about the headphones and how they performed. Most of the usb headphones I have seen sounded like garbage.
I really think a lot of it is workflow. When I thought about that AOL new IM noise I cringed. I like my bells to be visual.
You don't necessarily have to have two simultaneous sound sources. For example, if I want to connect a bluetooth headphone to listen to music, without PA I would need to edit my alsarc file and restart Firefox so it picks up the new sound card.
I find that with the default PulseAudio config, flat volumes make using headphones a pain because the same volume level means very different things on different hardware - so if I'd last used an application on speakers, I'd get deafened if it launched on headphones. I guess spending $$$ on USB-attached headphones would partially solve that problem by stopping apps from automatically switching to the headphones, but for me it'd be a rather expensive and inferior workaround.
I use an ALSA config for this on a multichannel sound card. I plug my headphones into the rear port, speakers into the front port, and turn down the rear volume with alsamixer.
> Those are 'soundcards' and switching sound between those wasn't really possible without PA.
It is possible. It just requires a manual (scripted) process of changing the default sound devices in your .asoundrc. Not that everyone would want to do that, but it is possible.
I do this by symlinking a different file to ~/.asoundrc and restarting whatever process is producing audio. Crude but it works.
In contrast the time I tried to set up pulse for this purpose I could not get it to produce any sound at all from any output device (everything working fine when stuff is talking directly to alsa).
I'm not sure if it is entirely fair to criticise alsa for lacking (g)ui -- after all there was a major shift to pulse audio, and pretty much all relevant ui projects (eg: gnome) basically went: use pulse or forget about easily switching audio i/o. It has very little to with alsa "as such". After finally tiring of how pulse-audio kept introducing lag and skips in my audio, I found alsa-heaven with:
$ cat ~.asoundrc
pcm.nvidia { type hw; card NVidia; }
ctl.nvidia { type hw; card NVidia; }
pcm.usb { type hw; card DAC; }
ctl.usb { type hw; card DAC; }
#pcm.!default pcm.usb
ctl.!default ctl.usb
#dmix for software mixing? http://alsa.opensrc.org/Dmix
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024 # Must be unique
slave {
pcm "hw:DAC"
}
}
Note that my usb dac doesn't do hardware mixing, but alsa handles that fine (I can watch a movie and play audio at the same time, yai!).
In general I feel that Linux audio seems worse now than in the 1.3 days -- but I'm not sure easy gui of pulse audio makes up for crappy resource utilization and general complexity of piping some binary data to a /dev/audio device.
I'd low to see something like jack with a easy-to-use ui and soft realtime (and optional network transparency) -- but right now it seems a little to hard to use for me (but that could be my usb dac that isn't quite a sound card, and reportedly has pretty crappy (alsa) drivers).
You know more about alsa than I do. Can you, with this setup:
- reduce single input streams (mute that one flash video) in volume?
- can you switch between usb and internal card without restarting an application? Use case: You're playing a game, wife enters the room, requests that you put on headphones. Trivial with PA (even with USB headphones), what about your pure alsa workflow?
> reduce single input streams (mute that one flash video) in volume
Not easily, as far as I know. What is the use-case for this, btw? Muting flash on sites other than youtube and the like (as youtube has a volume control for every video)? I use noscript and flashblock -- so I generally only see (hear) flash I want.
> switch between usb and internal card without restarting an application?
I haven't tried (no need -- I only use my dac for audio). Alsamixer allows you to set volume for each device, so perhaps one could set up a virtual device so that audio goes to both cards by default, and then you could mute one or the other there? Take a look at this thing I found:
[edit: For switching outputs/cards "manually" via using separate .asoundrc files, not the guide linked above]
I think restarting audio is enough (but that would typically not help for games, but should be fine for video (stop-start playback). [edit2: The app needs to close the audio device for such manual shifting to work -- YMMV]
I only ended up with this after enough frustration with pa that I went and looked up how to do (basic) alsa config. The documentation could benefit from more (hand holding) guides, and a proper (g)ui wouldn't hurt. But when you see it as a list of inputs and outputs (both plugins and devices) -- slaves and masters -- most setups are possible.
If you've used ALSA and Pulse for an extended time (assuming you used dmix), and you never found anything wrong with ALSA that you needed Pulse for, then you really aren't missing anything.
The pros of pulse are that it intercepts audio outputs from programs including legacy ones looking for OSS, it can work over a network (so you can have audio streams from one machine output on another) and nothing can ever grab the audio sink from pulse assuming you use the pulseaudio-alsa shim wrapper. I find this very useful, because it means the worst thing a misbehaving program can do is make some awful sounding trash underrun PCM nonsense come out of my speakers, but it can't seize my sound card.
Other advantages are that most GUI programs (Veromix is amazing) target pulse, but in practice you can use ladspa / lv2 plugins with alsa, you can use per-channel volume control and multiple outputs via dmix, and alsamixer is really intuitive even if it is ncurses based compared to pavucontrol.
From a developers perspective, having used alsa, pulse, ports, etc - I'd never touch any of that nonsense (again, at least, and if I don't have to). Depending on the applciation I'm either using gstreamer if I'm Linux native or SDL / QtMultimedia if I'm cross platform. But you get a lot of very peculiar sound mixing features from using alsa / pulse apis directly (pulse especially, you can do all kinds of nonsense to your streams) that might bind you to them over more abstract APIs.
Networking with pulseaudio is a pretty useful feature indeed. I've unfortunately never managed to make it work correctly with flash vids (e.g: youtube).
Are there actually programs that still use OSS? When I see OSS I think redhat rembrandt or picasso and kernel 1.2.12. I thought OSS was killed off in 2.2.x or 2.4?
> alsamixer is really intuitive even if it is ncurses based compared to pavucontrol.
I don't mind ncurses; to be honest I have never really complained about an ncurses interface compared to the gtk equivalent. It is funny that you mention QT, I will put up with pulseaudio even though I do not think I need it installed. QT/KDE is another story. I would like to use rkward but every time I type `apt-get --no-install-recommends install rkward` I take one look at the list of dependencies and say forget it. I think its nuts that a stats program depends on kde-runtime. If rkward just needed some extra qt libs (similar to gnumeric grabbing some gtk libs but not gnome-core) I would probably bite the bullet and install it.
I hope my reply did not sound bitchy, I appreciate you taking the time to explain the sound madness to me. Do you do professional audio work?
ALSA didn't get accepted into the kernel until the 2.5 series, so OSS was the default for all the Red Hat Linux releases and even the first Fedora Core release.
There are quite a few operating systems that didn't get dragged into the ALSA mess, like the BSDs. OSS versions of late have managed to solve the complaints people had which led to alsa, plus added things like virtual audio channels, so that apps think they're getting the full audio device. OSS support is more than a bit useful because everyone uses it.
I never even thought about WINE. I remember having trouble a long time ago with rossetta stone in WINE. I just checked the winehq sound wiki page[1] and it does not even mention OSS. I also just read that Ubuntu dropped OSS completely. That was news to me.
I always thought alsa was kind of overkill from the client program's perspective. There's something very appealing about your sound interface being a simple open(), ioctl(), and write(). Make whatever enhancements you need under the hood, but don't kill the simplicity of interface.
Given that the kernel ships with a compatibility layer I wouldn't blame someone for sticking with the old interface.
Oh, so bluetooth audio is broken now, if you want input as well (apparently not just for pulsaudio). That's great, I was just about getting ready to experiment with a2dp and friends :-(
Which would be a new feature. For me it only ever caused troubles (sound errors and huge latency and you can't get rid of it in Fedora). The only useful thing about it is that you can control the volume of each program even if the program itself does not provide such an control (some games are crappy like that). But that hardy justifies all the trouble it causes.
Interesting. My experience with PA ever since version 2.0 has been that sound just magically works. Like it has been on Windows and OS X for years now.
Another embarrasment for a Linux user is finally over. I think the last one to go is X11 => Wayland.
Is it perhaps the case that Pulseaudio is an example of a complex program where the original developers have gone elsewhere? All the easy bugs get fixed, the ones that require deep knowledge remain forever.
44 comments
[ 2.9 ms ] story [ 85.1 ms ] threadAnyone know the back story on the missing HSP/HFP support in BlueZ 5? Patent related?
Edit: it's mentioned briefly in the BlueZ 5 release notes (http://www.bluez.org/release-of-bluez-5-0/)
* BlueZ 5 support (A2DP only)
* Reimplementation of the tunnel modules
* Native log target support for systemd-journal
* Small changes here and there
* Many bug fixes
Personally it's probably been a year since last time I had to think about pulseaudio, which is the way I prefer it to stay.
Personally Pulseaudio has always been "that thing that fixes all those problems I never had with ALSA." I realize there is more to it than that but I have never really understood what pulseaudio does for me a casual sound user? Sound on my computer is exclusively produced by mpd, vlc and flashplugin-nonfree and I do not remember the last time I used a microphone on a linux machine.[1] I have browsed through the docs a couple of times but I have never figured out why, let alone how, I would want to change anything.
The only thing about Pulseaudio that I am confident of is that it is less overkill than jackd for my use cases. What am I missing?
[1]: I guess I have used the microphone a couple of times but it was always because I thought I would try Skype again. But this always resulted in a ton of wasted time with 32bit libraries and an avalanche of qt dependencies. I would get skype to work but I used it so rarely that by the time I needed it again I had to go through all the nonsense all over again.
It speaks volumes that Apple chucked their extant printing code in the bin and switched to CUPS as their printing backend, because CUPS was better than any of the alternatives available to them.
I tend to like headphones that are connected via USB. Those are 'soundcards' and switching sound between those wasn't really possible without PA.
I often like to look at the output sources and mute (or reduce in volume) some sources, leaving the rest intact.
My use cases really just revolve around those. Works fine for me. flashplugin-nonfree is a nice example for something to mute, btw..
I think a lot of this is just a difference in workflow. I don't think I have ever intentionally had two programs playing sound at the same time. NoScript/RequestPolicy/Adblock essentially mute flashplugin-nonfree for me. The only places flash runs are places where I want the sound.
Sound at the same time: Happens regularly for me. I'm listening to music and some IM client runs. I could mute that client (in the client itself) or .. reduce the volume of that one application (in PA). NoScript and RequestPolicy were too much of a hassle to me in the past tbh. I regularly end up with a braindead/moronic website playing some random video. Muting flash while I look for the offending tab makes me a much saner person.
I really think a lot of it is workflow. When I thought about that AOL new IM noise I cringed. I like my bells to be visual.
It is possible. It just requires a manual (scripted) process of changing the default sound devices in your .asoundrc. Not that everyone would want to do that, but it is possible.
In contrast the time I tried to set up pulse for this purpose I could not get it to produce any sound at all from any output device (everything working fine when stuff is talking directly to alsa).
In general I feel that Linux audio seems worse now than in the 1.3 days -- but I'm not sure easy gui of pulse audio makes up for crappy resource utilization and general complexity of piping some binary data to a /dev/audio device.
I'd low to see something like jack with a easy-to-use ui and soft realtime (and optional network transparency) -- but right now it seems a little to hard to use for me (but that could be my usb dac that isn't quite a sound card, and reportedly has pretty crappy (alsa) drivers).
- reduce single input streams (mute that one flash video) in volume?
- can you switch between usb and internal card without restarting an application? Use case: You're playing a game, wife enters the room, requests that you put on headphones. Trivial with PA (even with USB headphones), what about your pure alsa workflow?
Not easily, as far as I know. What is the use-case for this, btw? Muting flash on sites other than youtube and the like (as youtube has a volume control for every video)? I use noscript and flashblock -- so I generally only see (hear) flash I want.
> switch between usb and internal card without restarting an application?
I haven't tried (no need -- I only use my dac for audio). Alsamixer allows you to set volume for each device, so perhaps one could set up a virtual device so that audio goes to both cards by default, and then you could mute one or the other there? Take a look at this thing I found:
http://slack4dummies.blogspot.no/2012/02/alsa-multiple-outpu...
[edit: For switching outputs/cards "manually" via using separate .asoundrc files, not the guide linked above] I think restarting audio is enough (but that would typically not help for games, but should be fine for video (stop-start playback). [edit2: The app needs to close the audio device for such manual shifting to work -- YMMV]
I only ended up with this after enough frustration with pa that I went and looked up how to do (basic) alsa config. The documentation could benefit from more (hand holding) guides, and a proper (g)ui wouldn't hurt. But when you see it as a list of inputs and outputs (both plugins and devices) -- slaves and masters -- most setups are possible.
The pros of pulse are that it intercepts audio outputs from programs including legacy ones looking for OSS, it can work over a network (so you can have audio streams from one machine output on another) and nothing can ever grab the audio sink from pulse assuming you use the pulseaudio-alsa shim wrapper. I find this very useful, because it means the worst thing a misbehaving program can do is make some awful sounding trash underrun PCM nonsense come out of my speakers, but it can't seize my sound card.
Other advantages are that most GUI programs (Veromix is amazing) target pulse, but in practice you can use ladspa / lv2 plugins with alsa, you can use per-channel volume control and multiple outputs via dmix, and alsamixer is really intuitive even if it is ncurses based compared to pavucontrol.
From a developers perspective, having used alsa, pulse, ports, etc - I'd never touch any of that nonsense (again, at least, and if I don't have to). Depending on the applciation I'm either using gstreamer if I'm Linux native or SDL / QtMultimedia if I'm cross platform. But you get a lot of very peculiar sound mixing features from using alsa / pulse apis directly (pulse especially, you can do all kinds of nonsense to your streams) that might bind you to them over more abstract APIs.
Any success story would be greatly appreciated!
Are there actually programs that still use OSS? When I see OSS I think redhat rembrandt or picasso and kernel 1.2.12. I thought OSS was killed off in 2.2.x or 2.4?
> alsamixer is really intuitive even if it is ncurses based compared to pavucontrol.
I don't mind ncurses; to be honest I have never really complained about an ncurses interface compared to the gtk equivalent. It is funny that you mention QT, I will put up with pulseaudio even though I do not think I need it installed. QT/KDE is another story. I would like to use rkward but every time I type `apt-get --no-install-recommends install rkward` I take one look at the list of dependencies and say forget it. I think its nuts that a stats program depends on kde-runtime. If rkward just needed some extra qt libs (similar to gnumeric grabbing some gtk libs but not gnome-core) I would probably bite the bullet and install it.
I hope my reply did not sound bitchy, I appreciate you taking the time to explain the sound madness to me. Do you do professional audio work?
[1]: http://wiki.winehq.org/Sound
Given that the kernel ships with a compatibility layer I wouldn't blame someone for sticking with the old interface.
Another embarrasment for a Linux user is finally over. I think the last one to go is X11 => Wayland.
https://bugs.freedesktop.org/show_bug.cgi?id=62588
This particular bug was known as 741 back in 2009:
http://lists.freedesktop.org/archives/pulseaudio-bugs/2009-D...
Is it perhaps the case that Pulseaudio is an example of a complex program where the original developers have gone elsewhere? All the easy bugs get fixed, the ones that require deep knowledge remain forever.