Hacker News Reader

Comment by jcastro | Hacker News Reader

> I'm not sure why this seems to be remembered so wrongly?

It didn't work reliably on all chipsets/soundcards.

I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics.

I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.

In the early 00's (before PulseAudio), my desktop had an old SoundBlaster Live PCI card that was pretty common around the turn of the millennium. ALSA dmix Just Worked with that one.

Any other hardware I encountered required some kind of software mixing, IIRC. Not that my experience was extensive, but I got the impression that hardware or driver support for dmix wasn't that common.

> Any other hardware I encountered required some kind of software mixing, IIRC.

Yes, that was dmix :) And it fits the timeline, hardware mixing was killed off back then by soundcard vendors/microsoft, iirc.

Hardware mixing was killed, because it turned out that it is more efficient to mix several streams with CPU and move just a single one via the bus. It was also more flexible and without weird limits - for example, GUS could mix 14 streams at 44,1 kHz, and if you went above (up to 32), the frequency of each stream went down.

Dmix was that software mixing; in the early 00's there were some cards capable of mixing in hardware and dmix was not used for them.

Okay, I guess I've got it wrong then. Thanks for the clarification.

Indeed. It also glitches like hell in case of any system load.

That's why PulseAudio and PipeWire run as real-time. Or they should.

Back when Pulse was new and I was running Gentoo I used to help other Gentoo users get their real-time settings correct. I believe we used rtprio in limits.conf. I don't recall when RTKit became a thing.

If your sound daemon is running as real-time and still missing deadlines then there's something wrong with your system hardware. Or I suppose, the sound source feeding the pulseaudio daemon is not getting enough CPU time.

I think they indeed should run at a (low) real-time priority, but only if they are limited to a fraction of total available CPU power, with say cgroups or similar.

Otherwise they can easily lock up the system, and that should not be the default configuration.

Reply on news.ycombinator.com