@BalooUriza @zloygik The problem of PA from what I've seen in the wild on other people machines isn't that it doesn't works but that there is way too many controls that allow to mute the sound.

So:
SunAudio_OSS vs. PulseAudio.jpeg

@lanodan@queer.hacktivis.me @BalooUriza@social.tulsa.ok.us @zloygik@mastodon.ml I have to agree. I have a USB headset and for the life of me, I cannot get it to work properly.

@lanodan @zloygik @BalooUriza

JACK Audio Connection Kit be like:

hi

@flexagoon @zloygik @BalooUriza
qjackctl: Nerdy as fuck, UX looks like 70's synths but you see how the whole thing is set at once
pavucontrol: How many tabs and sliders and buttons can we put?

@lanodan @zloygik @BalooUriza pavu is good tho (although I just use the Pulseaudio module in Polybar)

@lanodan The problem with OSS is that it was only as capable as your sound card is, and most sound cards in the post "SoundBlaster is the standard" world only support one sound at a time. So you absolutely need to burn CPU cycles on PA or similar to downmix everything into a single sound if you haven't kicked up an old AWE Live 128 or something.

I honestly loved how straightforward OSS was, but the drawback is how completely unforgiving it is to cost-cut hardware.

@BalooUriza @lanodan those limitations only existed in OSSv3 and older.

@BalooUriza @lanodan

OSSv4+, still being developed and released and used by pros in the audio industry especially for its MIDI support:

Supported audio formats:
* Supports 8/16/24/32 bits/sample audio formats
* Supports sampling rates from 8KHz up to 200KHz
* Supports mono, stereo, quad, 5.1, 7.1 and multichannel audio devices


Transparent Software based Audio Mixer:

* Allows applications to share the same "real" audio device regardless of what format is requested by the application.
* Supports recording and full duplex in addition to playback.
* Ability to mix stereo and multichannel audio streams up to 7.1/200Khz/32bit.
* Supports full 24 bit range without loss of precision during internal computations.
* Each application has its own independant volume controls.
* Supports loop back recording. This enables you to "record-what-you-hear". Typically this is useful for recording streaming audio or trapping audio from applications
64bit internal processing guarantees audio fidelity and precision if the audio data needs to be converted.
* New device enumeration and mixer API makes it very easy to manage devices programatically.

@BalooUriza @lanodan

I forgot to mention that OSSv4 uses: "64bit internal processing guarantees audio fidelity and precision if the audio data needs to be converted."


I can't even find documentation on what Pulseaudio actually supports, just concerning notes like this

blog post from 2020:

> Here’s a super important limitation of Pulseaudio: It doesn’t change the sample rate while sounds are playing, so it can only change the rate while audio isn’t being used.

http://mclements.net/blogWP/index.php/2020/06/30/high-res-audio-on-ubuntu/

This hilarious train wreck:

https://unix.stackexchange.com/questions/585789/pulseaudio-detects-wrong-sample-rate-forcing-pulseaudio-a-sample-rate


Is it even possible to get bit perfect audio out of Pulse? I can't find any evidence of it.

@feld @BalooUriza This might be why lain had sampling rate troubles in few streams, lol

@lanodan @BalooUriza yep

✅ buy a Mac and get CoreAudio
✅ use FreeBSD which has a barebones OSSv4 inside
✅ install OSSv4 on Linux/BSD


There is no path to good audio on Linux with ALSA or Pulse, Jack, etc.

True story, but @SlicerDicer make jokes every day about "he who broke our audio". It was literally the tipping point that pushed us to FreeBSD back around 2008.


Hands off my audio Lennart!

@feld @SlicerDicer @BalooUriza Sadly Linux Kernel API is a trainwreck so building OSSv4+ is a bit of a mess when you keep using recent versions.

And it seems like the OpenSound version of OSSv4+ lacks a lot of Intel HDA drivers (not really surprising, their framework approach is why you can't get sound on stuff like Debian Stable for recent machines).

So I get great sound in 9front, probably would in FreeBSD and {Net,Open}BSD but Linux says no/maybe/no.

@lanodan @feld @BalooUriza @SlicerDicer I’ve had few problems with alsa/pulseaudio honestly — but, I’m old enough that I used OSS on Linux for many years when it was just the standard long before ALSA showed up.

ALSA fucking sucks, it sounds bad, it works bad, it just is bad, and it sucks. It was a huge downgrade and offered nothing good or useful. I hate it, but it does work fine for me. But I remember enjoying my sound quality in Linux so much in the old days, and that going away to it sounding just “average” when ALSA became a thing.

lol who knows, I mean, its open source maybe someday some geek with lose their shit and fix all this mess properly.

@feld It is not so much the quality of pulse now it's the choices and shortcuts taken. The way systemd has just consumed and consumed. What a mess that no one wants. Meanwhile I sit here after a decade of using FreeBSD? Still the same. I've heard it's been this way longer 🤣

@SlicerDicer @shebang this should make you cry

@SlicerDicer @shebang I remember this one actually

@shebang @lanodan @BalooUriza @feld

When modern (consumer) sound chipsets are nothing but PCM sinks, I don't know how different ALSA and OSS could possibly be.

@ademan @shebang @BalooUriza @lanodan ALSA had lots of problems like you request the sound card at 44100, it tells you it's 44100, but it is actually playing 48000

That's why Doom 3 was OSS not ALSA initially

http://zerowing.idsoftware.com/linux/doom/Doom3FrontPage/#head-d9e3fc970559e475ad2c70f1f80ace1b2083a781

@SlicerDicer and I were in the chat with TTimo working on Doom3 as he bitched about this. Some of us were beta testers of all the ID Software Linux ports.


5/8/2008:
18:58 <+TTimo> lying on the frequency then
18:58 <+TTimo> some alsa drivers do that
18:58 <+TTimo> you ask them a freq
18:58 <+TTimo> they say yes
18:58 <+TTimo> give you something slightly different
18:58 <+TTimo> so the buffer starts filling up

@feld @BalooUriza @SlicerDicer @lanodan @shebang that sounds like a hard way of outputting audio, like, instead of relying on the audio clock he feeds the buffer from his own timing routine?

@thor @shebang @feld @lanodan @SlicerDicer Probably to keep things in synch with the on screen action?

@BalooUriza @shebang @feld @lanodan @SlicerDicer yes of course but you could just put the audio in the right place in the buffer. if you have a sample clock or just make one by looking at how fast the interface is consuming buffers, you just align your audio events in the buffer currently being filled up

@BalooUriza @SlicerDicer @feld @lanodan @shebang kind of odd that he even has variable length buffers though, that's not typical audio engine design

@feld @lanodan @BalooUriza I didn't even realize OSS was still supported. I thought the project was abandoned many years ago. I use jack over alsa and it's quite robust configuration. I worked with sound recording and jack managed with high quality real time record and sound processing tasks even on weak CPU.
but I had to patch Palemoon to implement jack support, for instance. so it's not all that well supported everywhere. idk what about OSS support, really. maybe I should give it a try.

and PA has a strong bad reputation because of Poettering that generally created too much terrible designed and buggy software. this is just one of them.

@lanodan @BalooUriza @zloygik
I had to save this image