Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dreich
    replied
    Originally posted by trasz View Post
    The code is much simpler
    Adding more code, no matter how simple it is, results in higher orders of complexity.


    Originally posted by trasz View Post
    Resampling is common? How often you see media (samples, streams) with sampling frequency other than 44100Hz?
    All the time.
    Also keep in mind that resampling, apart from sample rate conversions, also includes bit-depth conversions and all the above need to be done with floating-point precision.

    Leave a comment:


  • trasz
    replied
    Originally posted by dreich View Post

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



    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.
    The code is much simpler, because there's no need for additional layers, daemons, libraries etc.

    Resampling is common? How often you see media (samples, streams) with sampling frequency other than 44100Hz?

    Leave a comment:


  • dreich
    replied
    Originally posted by trasz View Post

    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.

    Originally posted by trasz View Post
    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.

    Leave a comment:


  • trasz
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • trasz
    replied
    Originally posted by dreich View Post

    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.

    Leave a comment:


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

    Leave a comment:


  • bug77
    replied
    Originally posted by trasz View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • dreich
    replied
    Originally posted by trasz View Post
    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.

    Originally posted by trasz View Post
    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.
    Last edited by dreich; 19 January 2021, 03:04 PM.

    Leave a comment:


  • trasz
    replied
    Originally posted by dreich View Post

    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.

    Leave a comment:

Working...
X