4 ms·

Pipewire is replacing PulseAudio and I can finally say, it works great. Pulse was a great idea for its time, but it was poorly written and it took 10 years for

Pipewire is replacing PulseAudio and I can finally say, it works great. Pulse was a great idea for its time, but it was poorly written and it took 10 years for it to get to a point it didn't make you wish you could avoid using it.

qalmakka 5y ago
Also I think it's crucial to clarify that in my experience the vast majority of audio troubles on Linux are due to how buggy and shitty (and ubiquitous) Realtek soundcards are. Those integrated cards are junk, and they are buggy like hell, if you read the source code the drivers have to resort to doing what's basically black magic to get them to work, each single damn configuration has its own quirks, etc. This is also true for Realtek NICs though, almost everything those guys do is shitty as heck.
deeblering4 5y ago
This is a great example of the blessing/curse of gnu/linux. On the one hand, freedom and infinite flexibility. On the other hand... There’s is no high level structure or plan as a whole. Linux is only the kernel, and distributions set up the userspace in varying ways. So development is inherently fractured into numerous similar projects. These projects leap frog and replace each other over time. But there is a lot of effort spent in reinventing the wheel. Sometimes I wish that, for example, we could all settle on one window manager. Everyone could put efforts in the same direction, and make it awesome. Of course in reality that would never work, but in some ways it would be nice to see the same amount of refinement and consistency in the userspace as in the kernel.
baxuz 5y ago
So we had ALSA > PulseAudio > Pipewire. What's the next thing that works Great* for Linux? *Terms and conditions apply, not guaranteed to work in all cases. Doesn't support hardware decoding or positional audio among other features. If you are having issues please refer to section 4.2 – "It's free and open source" where it's stated that the User waives all rights to criticise the Work unless they contribute to the Linux kernel themselves.
- qalmakka 5y ago
  I honestly had issues with audio also on Windows, so I don't think what you are saying is completely true. Even on Windows you play the lottery every time you buy a motherboard or a laptop, and if you lose, you're stuck with a shitty sound card with worse drivers. For instance, my workplace gave me an HP Zbook which has a builtin Realtek sound card whose Windows drivers do not support separate volumes for speakers and headphones. If you unplug your headphone jack by mistake, the embedded speakers will promptly start blasting the entire room with whatever you were listening to at the same audio level you set for the headphones. The output source is even called "Speakers/Headphones". If you uninstall the official Realtek drivers, Windows uses the generic HDA driver from Microsoft which supports different, separate sound outputs for the headphones and speakers, but it doesn't have all the weird hacks required to make the HDA codec actually work fine, so setting the volume at more than 10% creates clicks and audio artifacts. On Linux the drivers have been patched to avoid these issues, so both jack sensing and separate audio levels work fine. Someone mentioned Pulseaudio having issues with front jack detection - this is an issue I had myself, and I discovered that the underlying cause in the case of my desktop machine was due to the sound card triggering random jack plugged/unplugged events. This sent Pulseaudio's jacksense logic haywire, because it repeatedly saw sinks appearing and disappearing. I tried to remove the Realtek drivers on Windows on the same machine and - voilà! A very similar issue occurs with the Microsoft generic driver, which leads me to think that the OEM driver does some black magic stuff underneath to get jack sensing work fine on their sound card. To get an idea of how buggy and terribile are the builtin soundcards shipped in consumer hardware, just look at FreeBSD's HDA audio driver, which is forced to apply hacks depending on the __specific model of laptop__ just to avoid audio glitches: https://github.com/freebsd/freebsd-src/blob/40923b0c81cc2c151388ec5ead59f4bed89ac432/sys/dev/sound/pci/hda/hdaa_patches.c#L382 https://github.com/freebsd/freebsd-src/blob/40923b0c81cc2c15...

qalmakka 5y ago

Also I think it's crucial to clarify that in my experience the vast majority of audio troubles on Linux are due to how buggy and shitty (and ubiquitous) Realtek soundcards are. Those integrated cards are junk, and they are buggy like hell, if you read the source code the drivers have to resort to doing what's basically black magic to get them to work, each single damn configuration has its own quirks, etc. This is also true for Realtek NICs though, almost everything those guys do is shitty as heck.

deeblering4 5y ago

This is a great example of the blessing/curse of gnu/linux. On the one hand, freedom and infinite flexibility. On the other hand... There’s is no high level structure or plan as a whole. Linux is only the kernel, and distributions set up the userspace in varying ways. So development is inherently fractured into numerous similar projects. These projects leap frog and replace each other over time. But there is a lot of effort spent in reinventing the wheel. Sometimes I wish that, for example, we could all settle on one window manager. Everyone could put efforts in the same direction, and make it awesome. Of course in reality that would never work, but in some ways it would be nice to see the same amount of refinement and consistency in the userspace as in the kernel.

baxuz 5y ago

So we had ALSA > PulseAudio > Pipewire. What's the next thing that works Great* for Linux? *Terms and conditions apply, not guaranteed to work in all cases. Doesn't support hardware decoding or positional audio among other features. If you are having issues please refer to section 4.2 – "It's free and open source" where it's stated that the User waives all rights to criticise the Work unless they contribute to the Linux kernel themselves.

qalmakka 5y ago
I honestly had issues with audio also on Windows, so I don't think what you are saying is completely true. Even on Windows you play the lottery every time you buy a motherboard or a laptop, and if you lose, you're stuck with a shitty sound card with worse drivers. For instance, my workplace gave me an HP Zbook which has a builtin Realtek sound card whose Windows drivers do not support separate volumes for speakers and headphones. If you unplug your headphone jack by mistake, the embedded speakers will promptly start blasting the entire room with whatever you were listening to at the same audio level you set for the headphones. The output source is even called "Speakers/Headphones". If you uninstall the official Realtek drivers, Windows uses the generic HDA driver from Microsoft which supports different, separate sound outputs for the headphones and speakers, but it doesn't have all the weird hacks required to make the HDA codec actually work fine, so setting the volume at more than 10% creates clicks and audio artifacts. On Linux the drivers have been patched to avoid these issues, so both jack sensing and separate audio levels work fine. Someone mentioned Pulseaudio having issues with front jack detection - this is an issue I had myself, and I discovered that the underlying cause in the case of my desktop machine was due to the sound card triggering random jack plugged/unplugged events. This sent Pulseaudio's jacksense logic haywire, because it repeatedly saw sinks appearing and disappearing. I tried to remove the Realtek drivers on Windows on the same machine and - voilà! A very similar issue occurs with the Microsoft generic driver, which leads me to think that the OEM driver does some black magic stuff underneath to get jack sensing work fine on their sound card. To get an idea of how buggy and terribile are the builtin soundcards shipped in consumer hardware, just look at FreeBSD's HDA audio driver, which is forced to apply hacks depending on the __specific model of laptop__ just to avoid audio glitches: https://github.com/freebsd/freebsd-src/blob/40923b0c81cc2c151388ec5ead59f4bed89ac432/sys/dev/sound/pci/hda/hdaa_patches.c#L382 https://github.com/freebsd/freebsd-src/blob/40923b0c81cc2c15...