4 ms·

Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of

by badsock 11y ago

Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.

the_why_of_y 11y ago
Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.
upofadown 11y ago
Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.
- badsock 11y ago
  If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level. Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.
andor 11y ago
PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are: * Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well) * Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call * Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency
digi_owl 11y ago
Supposedly network transparency came later. Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call). Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage. Also, i don't think Alsa had dmix (user-space software mixing) at that point in time. As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.

by badsock 11y ago

Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.

the_why_of_y 11y ago

Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.

upofadown 11y ago

Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.

badsock 11y ago
If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level. Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.

andor 11y ago

PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are: * Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well) * Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call * Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency

digi_owl 11y ago

Supposedly network transparency came later. Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call). Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage. Also, i don't think Alsa had dmix (user-space software mixing) at that point in time. As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.