PulseAudio Lands Much Better Support For FreeBSD - Audio Now Plays Correctly

[trasz]

How does FreeBSD handle this (multiple audio streams with independent volume control, resolution changes on the fly and such)?

By mixing audio where it makes sense: in the kernel sound framework. Unless you enable the bitperfect mode, by the very definition of bitperfect.

[dreich]

By mixing audio where it makes sense: in the kernel sound framework.

That makes no sense at all. No need to turn the kernel into Frankenstein's monster with mixing and effects chains.

[trasz]

That makes no sense at all. No need to turn the kernel into Frankenstein's monster with mixing and effects chains.

Things should be designed in a way that results in least complexity. Otherwise you'll end up with entire subsystems designed to work around bugs in other subsystems, like with PulseAudio.

There are no "effects chains", it's just mixing and (largely unused anymore) resampling.

[dreich]

Things should be designed in a way that results in least complexity.

That is precisely why implementing mixing "frameworks" in-kernel should be avoided at all cost. Providing said functionality via pulseaudio or sndio makes for a modular system where I can choose to install them if-and-only-if I need them. In short, I can keep all this volatile multimedia crap out of my way.

There are no "effects chains", it's just mixing and (largely unused anymore) resampling.

This is interesting because in order to mix different sources with different sample-rates assumes resampling them. Resampling is an integral part of mixing and is used all the time.

[Danielsan]

You can't escape from Pulse not even in FreeBSD...

[bug77]

Things should be designed in a way that results in least complexity. Otherwise you'll end up with entire subsystems designed to work around bugs in other subsystems, like with PulseAudio.

So... put everything in kernel, otherwise it's bad design?

ALSA is as much a kernel module as OSS is, so obviously that's not the differentiator here.
PA was not created to work around bugs. How could it, it still works on top of ALSA. And OSS. And the network.

[aht0]

When it's on certain conditions problematic for it's users - can it be claimed to be good design?

[trasz]

That is precisely why implementing mixing "frameworks" in-kernel should be avoided at all cost. Providing said functionality via pulseaudio or sndio makes for a modular system where I can choose to install them if-and-only-if I need them. In short, I can keep all this volatile multimedia crap out of my way.



This is interesting because in order to mix different sources with different sample-rates assumes resampling them. Resampling is an integral part of mixing and is used all the time.

The kernel is modular too; if you don't want sound, just don't compile it, or don't load it.

Resampling is only needed when you're trying to mix streams with different sampling rate, which is somewhat uncommon nowadays.

[trasz]

So... put everything in kernel, otherwise it's bad design?

ALSA is as much a kernel module as OSS is, so obviously that's not the differentiator here.
PA was not created to work around bugs. How could it, it still works on top of ALSA. And OSS. And the network.

There are two fundamental differences between those two: first, ALSA is proprietary and mostly undocumented, which makes it harder for people to use it directly. Second, it's missing some basic functionality which needs to be patched over, as seen above.

The network part of PulseAudio could make some sense, if it worked.

[dreich]

The kernel is modular too; if you don't want sound, just don't compile it, or don't load it.

The code is still added in the kernel making it more complex regardless.

Resampling is only needed when you're trying to mix streams with different sampling rate, which is somewhat uncommon nowadays.

As previously stated, resampling is very common these days which makes it an integral part of the mixing "framework" and unfortunately part of the in-kernel implementation which increases the overall complexity.