5 ms·

I don't even know why this is even necessary. Back in the day I just set up the ALSA daemon to save/restore volume levels and that was it. In all programs I se

I don't even know why this is even necessary. Back in the day I just set up the ALSA daemon to save/restore volume levels and that was it. In all programs I select ALSA as output and boom done. So I'm confused to why pulse audio and pipewire even exist.

denton-scratch 4y ago
Firefox can't do sound with raw ALSA. No, I know that doesn't explain why PulseAudio exists. But I think Pipewire can do more - isn't it supposed to be able to move video around as well as audio? Or something. I also just use raw ALSA. It's there anyway, it works, and I don't need more daemons (I don't need NetworkManager either).
bluGill 4y ago
Because the complexity of audio is hard. If you just have a desktop system with stereo speakers it is easy. However if you ever plug a set of headphones in things get hard. Should all sound now go through the headphones or not? Different people will want different answers (I have headphones plugged in all the time, but I'm not wearing them all the time, so if someone sends me an IM I need the beep to come out the regular speakers). There are monitors that have built in speakers making this harder, does the user have better speakers plugged into the computer output or not? That is the regular desktop user. If you do any for of audio processing (pod casting, music recording) you may have a large number of different inputs and output connected, and want to do mixing of some sort. Likewise if you do videos you may have more than one "webcam" that you want to mix. These are fairly common use cases (many people have a dream of being a musician or an actor, and so have this type of setup that they are trying to use in the efforts to make it big)
- jancsika 4y ago
  > Should all sound now go through the headphones or not? The correct answer to that specific question: as a sane default, all sound should now go through the headphones. That's a sane default on the Iphone, probably on Macbooks, and it also happens to be the one that at least a stock Gnome or Ubuntu desktop chooses. In fact I have trouble thinking of a saner default than that one! Forgetting about sane defaults seems to be a common problem in FOSS communication. It's unfortunate, because describing something as unknowable can convince a new developer to avoid inspecting the code around that particular problem. E.g., it took a long time for Gnome to get the sane default I describe above. I'd bet that lurking in the appropriate mailing list history is at least one didactic post from an audio developer explaining how we can never truly know what a user's preferred setup could be.
amaranth 4y ago
Raw ALSA can only have one program playing sound unless your hardware has support for hardware mixing (this would generally mean it's very old and also very expensive). More likely you are/were using ALSA's dmix plugin which is a small barebones version of the core functionality of pulseaudio or pipewire. They replace dmix but also give you things like per-program volume control, better latency, better power usage, better mixing, bluetooth support, the ability to do fancy things with audio routing without restarting every program playing audio, etc.
- codedokode 4y ago
  I am not sure about "better latency". The latency with Pulseaudio cannot be controlled via GUI and is often quite large (on order of hundred ms or more). In my opinion, to get minimum latency one needs to access audio card directly, without intermediate daemons.
  - seba_dos1 4y ago
    PA isn't great when it comes to latency, but JACK and PW are.
  - amaranth 4y ago
    PulseAudio optimizes for power consumption but tries to be adaptive to handle lower latency as well. PipeWire seems to optimize for latency but try to be adaptive to reduce power consumption as well. These are conflicting desires, lower latency requires higher power usage because you have to use shorter buffers instead of just giving the sound card a big chunk of audio to work through and putting the CPU to sleep. JACK could potentially still do better and ALSA could potentially still do better than even that but PipeWire's goal is to be close enough or even match JACK while still having all the other features people use PulseAudio for.
- traverseda 4y ago
  I'm not really sure what the difference between "ALSA just works" and "ALSA as configured by my distribution and including the DMIX plugin just works" is. Like at the end of the day option 2 is still "ALSA just works".
kobalsky 4y ago
pulseaudio exists because it's user friendly. JACK exists becase some people need low latency and dynamic control over non-trivial audio routing. pipewire attempts to bring the best of both worlds and make it container friendly for security purposes.
- codedokode 4y ago
  > JACK exists becase some people need low latency Wouldn't latency be lower if the application would access audio card directly without any daemons in between?
  - seba_dos1 4y ago
    Then you would only be able to do fraction of functionality JACK provides you. May be enough for the most simple use-cases, but people who reach for JACK aren't usually after those.
  - wtay 4y ago
    The answer is, surpisingly maybe, no. JACK (and PipeWire) manage to add features without adding any latency to what ALSA can provide. Will it consume more CPU? yes, it does...
codedokode 4y ago
Because ALSA doesn't allow two programs to use the same audio card simultaneously. ALSA is good for exclusive access, when you want to remove everything between an application and audio card. Also ALSA cannot do other nice things, like switching audio output when you plug an USB audio card.
- traverseda 4y ago
  It can and does as it was configured by most distributions.
  - doodlesdev 4y ago
    The dmix plugin does, not ALSA.
coldpie 4y ago
Because they do things many users find useful: -Per-application volume control -Seamless hardware switching mid-stream (plug in headphones) -Different channel configurations into the same device simultaneously -Cross-application volume ducking
rjzzleep 4y ago
Most of the things people below say ALSA didn't have, OSSv4 actually had. But basically, they made it proprietary, Linux switched to ALSA, and when OSSv4 became open source again it lost traction. But from my experience at the time, it had none of the problems ALSA had, it had none of the problems pulseaudio had, and it had none of the problems ESD had. This is a clear case of when ideology won over an objectively better product to the detriment of all users for more than a decade.
- coldpie 4y ago
  Ehhhh OSS is really not great, even v4. Re-using Unix file I/O functions for audio sounds clever, but falls apart pretty quickly in the real world. Even in the best case where you manage to shove every audio feature into open, read, write, and ioctl, it's never going to feel good to use (type safety...). I don't mourn the loss of OSS.
- wtay 4y ago
  OSS relies on mixing in the kernel, which is bad for reasons explained here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#why-cant-we-just-use-oss-and-mix-everything-in-the-kernel https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... Also with OSS you still can't seamlessly switch between devices, bluetooth or arbitrary signal routing between apps. So, no... good riddance.

denton-scratch 4y ago

Firefox can't do sound with raw ALSA. No, I know that doesn't explain why PulseAudio exists. But I think Pipewire can do more - isn't it supposed to be able to move video around as well as audio? Or something. I also just use raw ALSA. It's there anyway, it works, and I don't need more daemons (I don't need NetworkManager either).

bluGill 4y ago

Because the complexity of audio is hard. If you just have a desktop system with stereo speakers it is easy. However if you ever plug a set of headphones in things get hard. Should all sound now go through the headphones or not? Different people will want different answers (I have headphones plugged in all the time, but I'm not wearing them all the time, so if someone sends me an IM I need the beep to come out the regular speakers). There are monitors that have built in speakers making this harder, does the user have better speakers plugged into the computer output or not? That is the regular desktop user. If you do any for of audio processing (pod casting, music recording) you may have a large number of different inputs and output connected, and want to do mixing of some sort. Likewise if you do videos you may have more than one "webcam" that you want to mix. These are fairly common use cases (many people have a dream of being a musician or an actor, and so have this type of setup that they are trying to use in the efforts to make it big)

jancsika 4y ago
> Should all sound now go through the headphones or not? The correct answer to that specific question: as a sane default, all sound should now go through the headphones. That's a sane default on the Iphone, probably on Macbooks, and it also happens to be the one that at least a stock Gnome or Ubuntu desktop chooses. In fact I have trouble thinking of a saner default than that one! Forgetting about sane defaults seems to be a common problem in FOSS communication. It's unfortunate, because describing something as unknowable can convince a new developer to avoid inspecting the code around that particular problem. E.g., it took a long time for Gnome to get the sane default I describe above. I'd bet that lurking in the appropriate mailing list history is at least one didactic post from an audio developer explaining how we can never truly know what a user's preferred setup could be.

amaranth 4y ago

Raw ALSA can only have one program playing sound unless your hardware has support for hardware mixing (this would generally mean it's very old and also very expensive). More likely you are/were using ALSA's dmix plugin which is a small barebones version of the core functionality of pulseaudio or pipewire. They replace dmix but also give you things like per-program volume control, better latency, better power usage, better mixing, bluetooth support, the ability to do fancy things with audio routing without restarting every program playing audio, etc.

codedokode 4y ago
I am not sure about "better latency". The latency with Pulseaudio cannot be controlled via GUI and is often quite large (on order of hundred ms or more). In my opinion, to get minimum latency one needs to access audio card directly, without intermediate daemons.
- seba_dos1 4y ago
  PA isn't great when it comes to latency, but JACK and PW are.
- amaranth 4y ago
  PulseAudio optimizes for power consumption but tries to be adaptive to handle lower latency as well. PipeWire seems to optimize for latency but try to be adaptive to reduce power consumption as well. These are conflicting desires, lower latency requires higher power usage because you have to use shorter buffers instead of just giving the sound card a big chunk of audio to work through and putting the CPU to sleep. JACK could potentially still do better and ALSA could potentially still do better than even that but PipeWire's goal is to be close enough or even match JACK while still having all the other features people use PulseAudio for.
traverseda 4y ago
I'm not really sure what the difference between "ALSA just works" and "ALSA as configured by my distribution and including the DMIX plugin just works" is. Like at the end of the day option 2 is still "ALSA just works".

kobalsky 4y ago

pulseaudio exists because it's user friendly. JACK exists becase some people need low latency and dynamic control over non-trivial audio routing. pipewire attempts to bring the best of both worlds and make it container friendly for security purposes.

codedokode 4y ago
> JACK exists becase some people need low latency Wouldn't latency be lower if the application would access audio card directly without any daemons in between?
- seba_dos1 4y ago
  Then you would only be able to do fraction of functionality JACK provides you. May be enough for the most simple use-cases, but people who reach for JACK aren't usually after those.
- wtay 4y ago
  The answer is, surpisingly maybe, no. JACK (and PipeWire) manage to add features without adding any latency to what ALSA can provide. Will it consume more CPU? yes, it does...

codedokode 4y ago

Because ALSA doesn't allow two programs to use the same audio card simultaneously. ALSA is good for exclusive access, when you want to remove everything between an application and audio card. Also ALSA cannot do other nice things, like switching audio output when you plug an USB audio card.

traverseda 4y ago
It can and does as it was configured by most distributions.
- doodlesdev 4y ago
  The dmix plugin does, not ALSA.

coldpie 4y ago

Because they do things many users find useful: -Per-application volume control -Seamless hardware switching mid-stream (plug in headphones) -Different channel configurations into the same device simultaneously -Cross-application volume ducking

rjzzleep 4y ago

Most of the things people below say ALSA didn't have, OSSv4 actually had. But basically, they made it proprietary, Linux switched to ALSA, and when OSSv4 became open source again it lost traction. But from my experience at the time, it had none of the problems ALSA had, it had none of the problems pulseaudio had, and it had none of the problems ESD had. This is a clear case of when ideology won over an objectively better product to the detriment of all users for more than a decade.

coldpie 4y ago
Ehhhh OSS is really not great, even v4. Re-using Unix file I/O functions for audio sounds clever, but falls apart pretty quickly in the real world. Even in the best case where you manage to shove every audio feature into open, read, write, and ioctl, it's never going to feel good to use (type safety...). I don't mourn the loss of OSS.
wtay 4y ago
OSS relies on mixing in the kernel, which is bad for reasons explained here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#why-cant-we-just-use-oss-and-mix-everything-in-the-kernel https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... Also with OSS you still can't seamlessly switch between devices, bluetooth or arbitrary signal routing between apps. So, no... good riddance.