[hedora]

Even so, surely it would have been easier and better to just fix or replace dmix (in kernel, in the existing data path) than introduce a userspace daemon, break API compatibility, and so on.

It’s been 20 years and pulseaudio is still flaky / high latency / incomprehensible. Professional flows that care use stuff like jack.

[anthk]

TBH pipewire works much better than pulse, up to the point to replacing jack itself. But DMIX worked fine for non-professional user needs and with very low CPU usage. Yes, it was Jackd for the professional but Windows had ASIO drivers too.

[account42]

Pipe might work better than pulse but it's still an overcomplicated mess compared to ALSA, which is itself an overcomplicated mess compared to OSS, which could have been easily made to support concurrent clients to /dev/dsp without all the API breakages and flaky deamons we had to suffer through.

[mjg59]

Doing audio mixing well is something that is, for a number of reasons, hard to do in kernel. And if you're still using pulseaudio, why? The rest of the world's moved to pipewire, which also provides a jack-compatible interface.

[loeg]

> It’s been 20 years and pulseaudio

PipeWire replaced Pulse like five years ago; who is using Pulse at this point to make statements like "20 years" meaningful? It isn't really an ongoing concern.

[bzzzt]

Pulseaudio came with an ALSA plugin which meant applications written for the ALSA API could output to PA so it was compatible.