Why is audio on linux so fucking shit?

Why is audio on linux so fucking shit?

Attached: linux-audio-stack.png (430x243, 60K)

Because it needed to be part of X11, so that it would take the same paths as graphics and be managed in much the same way.

It's not like it's any less of a clusterfuck on Windows, where there are also multiple audio interfaces, including third party ones like ASIO.

sounds fine here

Attached: air-motion-transformer-hedd-600px-2.jpg (600x600, 55K)

>Because it needed to be part of X11
so wayland will solve this issue as well? thank god

>*kernael swaps card interface index*
heh

The windows one is just as bad, you just dont notice.
It has nothing to do with X11.

>you just dont notice.
Seems like an improvement

It would be the same on lunix if pulseaudio wasn't poetteringware

ALSA/ASIO, PCM... It's the same on every OS.
Many programs will allow you to configure output directly from ALSA if you're feeling autistic.

Attached: foetering.jpg (864x576, 147K)

It's not. Compared to WDM, ALSA is many times better at handling audio processing, especially in realtime contexts. ASIO drivers provide comparable performance but require exclusive control over audio devices. Trying to set up a complex audio environment in Windows is a complete bitch; unless you want to write your own loopback driver, you're required to use ones provided by 3rd parties (VB-Audio) and they all offer shit quality playback or fuck up the signal. With PulseAudio you can create loopbacks or virtual sinks and sources using a simple pactl command.
This is blatant misinformation. None of the sound systems available for Linux rely on X11 in any way. ASIO is also a driver protocol, not an interface.

freetards made their own sound system for no reason and it was shit of course

>None of the sound systems available for Linux rely on X11 in any way
That's what I'm saying, and that's a problem in terms of making stuff just work. There should be a single pathway for audio and video, not the split that we currently have.
>ASIO is also a driver protocol, not an interface
>driver protocol
>not an interface

pipewire.org

>no bluetooth without pulse
kek and there's people who say alsa is enough

werks on my machine.

Attached: CopyQ.CmXarI.png (172x172, 5K)

Driver protocols are not interfaces, ASIO4All would be an interface, ASIO itself isn't.

Why should video and audio in a single pathway? That's not going to help make things "just work", you're still going to have to implement a sound system to manage streams and handle processing. Take your pseudo-intellectual bullshit suggestions elsewhere.

It good enough for the end user though

X11 is a display server, you shouldn't have it also be a sound system, it would make the already massive clusterfuck X11 is an even bigger one than it already is, which is completely counter-productive to making things "just werk".

>Why should video and audio in a single pathway
For the exact same reason all the stuff that is currently handled in X has a single pathway. Chances are, if your application outputs audio, it also displays a window, and takes user input from keyboard/mouse.
You could just configure your audio device as part of your X server, and then applications on that X server would have their audio routed to the correct place.
Remote X forwarding? Great, you don't have to do any additional work to get audio to forward. Currently, if you wanted to do this, you'd have to configure the audio forwarding separately, whereas on Windows with RDP, audio forwarding just works (it's not exactly the same as what I'm talking about, but the point is it actually functions with no extra configuration needed).

audio and video have to be synchronized, it's funny unix tried to build network transparency into the windowing system but still ended up inferior at remoting in every way

i think systemd should handle audio and video too lenny

Nobody uses this much shit all at once

It's a flow chart. You choose a path.

>if your application outputs audio, it also displays a window, and takes user input from keyboard/mouse
This is only true with respect to desktop applications; and even then, popular daemons like mpd don't require a graphical application to be used. Most audio servers are headless and have zero need for a display server. Having both audio and display handled by a single server just adds needless complexity and goes against the benefits of UNIX philosophy. Whether it's handled by X or through ALSA you still need to have a sound system implemented that handles routing, it's not going to make the process any simpler to manage for the end user because they still need to configure a device and set it on a per-application basis if they have more than one device. Developers still need to implement support for either in their software.

>remote forwarding
>it just works and you don't have to configure it
Windows provides an already configured environment that makes this possible, they don't have both their audio and display handled by a single server. If you want audio/display remoting to just work install a distro where it's already configured.

>audio and video have to be synchronized
Synchronization wouldn't be handled differently through implementing a sound system in X. Again, integrating a sound system into X would just make X needlessly complex and likely provide either a worse or essentially the same experience as using ALSA.

because you get red hat situations: dilettantes thinking "HEY WHAT FUNCTIONALITY SHALL I REINVENT WITH DBUS AND HTTP NEXT?" with (relatively) big money and clout backing whatever stupid, poorly designed shit they come up with

the result every time this happens? more fragmentation, more broken software, more mutual dependency growing like a tumor, and of course desktop linux users have always been used to things being a fucking mess, so they don't know any better

you're mistaking end-user interface with implementation detail

Mint 17.2 here.
Works great on my machine.
More gaymes than I have time to play and all run great (thanks, Valve).
Video playback works perfectly.
Speakers, cheap chinkshit bluetooth, and logitech g930 headphones all works great.

You could easily make a stripped down server that only supports audio if video isn't needed.
>Having both audio and display handled by a single server just adds needless complexity and goes against the benefits of UNIX philosophy
It's less complexity overall. I don't think anyone can look at the current state of Linux audio and think it's not needlessly complex.

The unix philosophy is overrated anyway. Look at ZFS - it's the exact opposite of muh unix philosophy and yet it's far better than any simple FS that doesn't try to pull in other layers of the file storage stack. There are plenty of situations where the unix philosophy is completely unwarranted and carries no real advantage - AV is one of them.

oh shit look out it's another guy with a STRONG OPINION on the unix "philosophy" who doesn't even seem to know what it entails

storage pool != retarded kitchen sink program design

BSD be like: If you want to play sound just write to /dev/dsp
Linux be like: Lets introduce a bunch of IOCTLS that make it impossible to play sounds on any system without additional libraries and binaries.

now you've done it. cue ten retards who were probably all of 3 years old when the ALSA was invented saying "OSS couldn't do such-and-such" -- yes it could, and if it couldn't, probably like 40 lines needed to be modified to add the feature.

i fucking hate porting to linux because of shit like the audio clusterfuck. not only is linux a moving target, it is a shapeshifting target and you have absolutely no assurance that what works on one person's machine (with a fresh distro install) will work on another person's machine (with fresh install of any other distro).

I don't know, even if you spend days searching/reading/configuring it still doesn't sound as good as with windows. Some kind of fundamental flaw in the software.

bazaar

the flaw is named Lennart Poettering

I would agree with you, but now I feel like audio is better in Linux. At least Linux can make use of my Bluetooth adaptor as an audio source - windows can't do that (but please correct me if I'm wrong).

>linux audio is complex
>meanwhile on Windows you need to install a proprietary 3rd party driver just to have a direct path to hardware instead of going through WDM, WASAPI and their audio effect engine.

How many layers of bullshit DirectSound have to go thru?

The Linux ecosystem is a consistent history of footgun decisions
>we could use OSS, but what if we made our own audio stack(s)?

DirectSound sessions are emulated by WASAPI in every major Windows release starting at Vista so there's no direct path if your application supports it. If you're using Windows prior to Vista DirectSound provides a direct path to audio hardware.

what are you talking about windows has their own sound drives

Attached: 1551598495066.png (980x485, 33K)

My USB headset requires me to have “videos” open with a paused video at max volume. If I don’t do this then I can’t lower the volume of any other application I’m using or else the sound will prematurely cut out. Wish there was a fix besides have videos application open every time I use the pc but it’s not that bad I guess.

pic related

Its more likely your fucking shitty speakers.

>>meanwhile on Windows you need to install a proprietary 3rd party driver just to have a direct path to hardware instead of going through WDM, WASAPI and their audio effect engine.
Guess what: that's something that 99.9% of users have absolutely no need for. Meanwhile windows audio works better for the stuff that the vast majority of people actually use it for.