10 ms·

The Linux audio stack demystified (and more)

155 points by ruffyx64 2y ago

thriftwy 2y ago
I remember there was oss and alsa. Then on top of that you had esd or artsd, with incompatible APIs and userland delays. Then at some point they were replaced with pulseaudio. I've just noticed now that pulseaudio is also replaced with pipewire in latest Ubuntu. That does not instill confidence in that they have any idea what they are doing. I remember that as far as on 2012 some Linux game ports from Steam (before Proton was a thing) failed to play sound. Other than that, it took them a decade to figure out that sound should switch to HDMI when it is plugged in. It may still require arcane config changes and may break down. I've opened the post to read about pipewire, and it seems that clicking an anchor does nothing. So it's not only sound they can't get right.
- shmerl 2y ago
  Don't worry, Pipewire is a very good development.
- Cloudef 2y ago
  Pipewire unifies all the apis, and is fully backward compatible. It has own API too, but you don't have to use it. You can write app using any of the apis, alsa, pulse, jack, and pipewire can work with it. You only need pipewire api if you need more control or pipe through video as well. JACK is very flexible approach to audio (think of unix pipes but audio) and this is what pipewire is inspired by, but targets the general desktop use and not just audio production as JACK does. Generally pipewire stays out of the way and works as pulseaudio replacement, but with the pipelines you can do a lot as a power user. Personally I think pipewire is one of the best things that has happened to linux, and since it shims all the previous audio apis instead of trying to tape the existing solutions into the package, it actually removes bloat from your system and you don't have to write weird libasound config files anymore.
shmerl 2y ago
> ALSA is the core layer of the Linux audio stack. It provides low-level audio hardware control, including drivers for sound cards and basic audio functionality. > ... > Ulike PuleAudio and JACK, PipeWire does not require ALSA on a system, in fact if ALSA is installed the output of ALSA is very likely pushed through PipeWire I don't get this part. If ALSA represents the kernel level hardware drivers for audio, how does Pipewire bypass it? Does it implement an alternative set of kernel drivers? I assumed Pipewire still relies on ALSA base.
- bornfreddy 2y ago
  This. Also, how does PulseAudio not support videoconferencing?
  - shmerl 2y ago
    May be it's about a higher layer of ALSA API, not about actual hardware drivers.
    - exe34 2y ago
      yeah I think there are two ALSAs, one in the kernel as drivers and one as a userspace library.
  - ruffyx64 2y ago
    Well. PulseAudio is a plain sound server. It does not handle video at all.
- bigstrat2003 2y ago
  I was also confused by this bit. If ALSA is part of the kernel, how can it not be installed?
  - SSLy 2y ago
    The article doesn't note kernel-ALSA and the old userspace-ALSA libraries that apps use to push audio.
g15jv2dp 2y ago
I now have flashbacks to when I tried to get sound working on my Gentoo install 15 years ago. It seems that now everything has changed (wtf is pipewire) and still requires arcane knowledge to get everything working smoothly...
- shmerl 2y ago
  Pipewire is a major development that's especially important for Wayland desktop. It was hard to miss unless you haven't used Linux in a long time.
  - nlpparty 2y ago
    I don't know what Pipewire is as well. I've used Linux daily for 10+ years, but I've never bothered to use Wayland.
    - shmerl 2y ago
      Well, time to move with the progress. I've been using KDE Wayland session for several years already.
      - exe34 2y ago
        nah I'm okay thanks. X11 still works flawlessly for me.
        shmerl 2y ago
        The main issue is that X11 is an increasingly unmaintained case and all new development happens with Wayland anyway. So as long as you can deal with lack of support - I guess no need to move, but otherwise Wayland with KDE has been well usable for a while already.
        exe34 2y ago
        Yeah I'll move when I have hardware that really needs it. I use a 12 year old laptop.
Galicarnax 2y ago
The text has a strong GPT-ish flavor.
- ssahoo 2y ago
  Gpt is just emulating best writing quality. This article is very well written. If it was gpt generated, I'd be happy to read more like it.
  - bowsamic 2y ago
    I genuinely think humans are going to degrade their writing style in order to sound less like an LLM
  - pickledoyster 2y ago
    I'd argue gpt emulates the lowest (i.e. cheapest to mass produce) passable quality writing optimized for longest page time/views
kmarc 2y ago
I hear many complaining (even here) about "the mess" of linux audio. First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source. Second: linux is the only platform where everything works right now flawlessly for me: My Bose joins without any problems, switches to headset mode during zoom calls, switches back to high definition audio otherwise. I can select a different sink, even networked, whenever I want the output to appear on a different networked device. MacOS sometimes needs a reboot so that the bluetooth subsystem works, what the hell. And all this worked with PulseAudio, and now works with Pipewire, which is an even higher quality iteration of PA. I don't complain. I wish MacOS/Windows had such a versatile, configurable, but sanely-working-out-of-the-box audio system as an off-the-shelf Fedora, or even freaking Arch linux has. HTH [1]: https://blog.rtrace.io/images/linux-audio-stack-demystified/pulseaudio-architecture.png https://blog.rtrace.io/images/linux-audio-stack-demystified/...
- bux93 2y ago
  I'm sure the windows audio stack is many times more complex, and it's pretty opaque. OEMs also love to include all kinds of audio related bloatware, which makes getting audio hardware to work reliably(!) quite challenging. The HP laptop I'm typing this on has an "Intel microphone array" (just 2 mics) which has it's own intel drivers, but there's also some HP control panel, realtek and 'sound research' branded stuff, Fortemedia SAMsoft effects(?), Intel smart sound... If I'm recording seriously, I usually just go to the device manager (devmgmt.msc) and disable as much as I can and enable devices in a trial-and-error way to see what the minimum is to get audio to work again. Otherwise, all kinds of 'enhancements' end up in the audio path.
  - hparadiz 2y ago
    If Windows could do what Linux can out of the box VoiceMeter would not exist.
    - 2y ago
sihox 2y ago
It's pretty nice article but for me - just for introductory purposes. It shows how sound and digital audio works and what basic libraries and tools we have in linux to deal with sound. But I'm still stupid when it comes to details and user interface tools. The article(s) I really love to see is, on one hand, more technically detail-specific and, on the other hand, broadly defining options I can have as an end user. I mean - from basic tools (CLI, GUI) that are available for simple purposes like volume control, stream selection, etc. to pro-audio, complex scenarios. For me it's too many tools and options I can use in linux for audio and this is the reason for being lost sometime. Of course for daily use I have pipewire with pulse, alsa and jack "plugins" which gives me seamless cooperation with lots of apps and controls but maybe I can get rid of some module or app...
Cloudef 2y ago
Pipewire has pretty much unified the userland linux audio stack (+ supports video as well as bonus). Kernel side it has always been alsa. There's TinyAlsa so you don't have to use libasound to interface with the kernel alsa. (userland alsa is quite PITA)
- alexey-salmin 2y ago
  > Kernel side it has always been alsa. Well you probably didn't mean it in a literal sense, but it was OSS up to kernel 2.4 and 2.6 had both OSS and ALSA
hcfman 2y ago
Beautiful work
laserbeam 2y ago
Here's my background 1. I have to modify my audio settings every time I start a call in Teams on Linux because it keeps losing my audio device. 2. In my audio settings UI, half the time I switch my devices the speaker test doesn't work. 3. In my audio settings UI, whenever I switch my mic I hear myself. The mic feedback only disappears 30 seconds after I close the settings UI. 4. My work headsets have a robotic sound (likely caused by an incorrect bitrate or buffer size). I can only use work bluetooth headsets via their dedicated dongle. This was my default experience on a popular debian based distro. And it mirrors the general experience I see online. Things are unstable and a mess. I started reading this article and it's embelished with phrases like: "is a professional-grade audio server", "widely used in professional audio production environments", and general language that sounds like a sales pitch. This does not fit with anything I'm familiar with. I would have preferred a neutral and semi technical approach, with 10% of the buzzwords. As written, I trust nothing.
- n_plus_1_acc 2y ago
  1. Is a known Problem with Teams
  - laserbeam 2y ago
    Yeah, teams definitely shares in the blame there. That one hurts more and I blame both microsoft and linux.
    - pedrocr 2y ago
      The Teams web app works very well in Chrome. I only miss being able to set a custom background to my video and popping out presentations into their own window. It seems much lighter on resources too, maybe because Chrome does more of the video encoding or decoding using hardware.
- juujian 2y ago
  That would be your headset being in headset mode. I'm on Debian Testing, and I'm finally able to exit headset mode and use a high quality audio codec instead. I hope that's the direction Linux is heading.
gen2brain 2y ago
Whenever someone mentions Linux and Audio I always remember this image (made by Adobe I think) https://harmful.cat-v.org/software/operating-systems/linux/audio-mess.png https://harmful.cat-v.org/software/operating-systems/linux/a.... It is missing Pipewire but it should be easy to add a dozen of new lines. This is the reason why I simply use plain ALSA without any sound daemons.
- pedrocr 2y ago
  That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.
  - creshal 2y ago
    Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.
    - gen2brain 2y ago
      And then there is Pipewire with PulseAudio plugin, and not to mention you can compile Pipewire with support for GStreamer, Jack, etc. I guess we can remove only the Arts and ESD daemons from that list, but the mess just adds up.
    - hawski 2y ago
      Aren't most of the libs you mentioned cross-platform or with a very specific use in mind which have direct analogues in Windows world?
      - creshal 2y ago
        Correct. You can draw just as messy a diagram for Windows. DirectSound versus OpenAL versus gstreamer(win32) versus jack(win32) versus XAudio2 versus DirectShow versus DirectMusic versus WDM Audio versus WASAPI versus UAA versus … If there's any difference it's that under Windows, the only debugging and error handling you have is "lol reinstall all drivers and codecs and pray".
poakjsn 2y ago
Linux distros would be best off lifting as much as possible from the Android Open Source Project, i.e. a professional and streamlined Linux-based system that actually works and isn't just a mishmash of incompatible, poorly designed hobbyist trash. The year of the Linux desktop never arrived but most of the world has Linux sitting in our palms. Let's build on that instead of the dead ends of Debian, Slackware, etc.
- probablybetter 2y ago
  wow. no. debian is the opposite of a dead end. now, ubuntu and lubuntu and xubuntu = i agree. android, however, is garbage. - it most certainly is not consistent across devices and editions - having to do phone-like-stuff on a desktop/laptop is painful - i hate Android. It's settings bother me the most. there is ZERO organization here! There are DARK patterns galore, it's built to dissuade you from doing anything serious. I can only take your comment as either a joke, or you literally only use a phone/tablet in life. news flash: Android audio is ALSA at it's core. Additionally: native Android audio is ultra-high-latency... completely unacceptable for pro-audio
- curt15 2y ago
  Hasn't Android audio always struggled with input latency?
  - Ylpertnodi 2y ago
    I use several audio apps on Android, on a mid-low phone. The most intensive use comes from Cubase - Audio and synths, mixer, inputs and outputs, midi/ phone input program. After 30 years on Atari then windows I've had my ups and downs with the program, but I can easily say that my android version is a1 solid, connected to/ from my hardware synths
cod1r 2y ago
An issue I've experienced very often is that sometimes when my laptops goes to sleep and I wake it up, the speakers occasionally aren't switched to unless I restart pipewire. Same thing for headphones, sometimes when I plug them in, they aren't switched to unless I replug it in a couple of times. Might be hardware related but situations like this make me feel like I should just use linux for servers instead of for a personal computer.
- trelane 2y ago
  What version of Linux did your laptop ship with?
  - cod1r 2y ago
    It had Fedora 36. So maybe Linux kernel 5.17 I have the latest kernel version now.
    - trelane 2y ago
      It's more about what distro the hardware vendor supports. What vendor and model laptop was it? I'll make a note to avoid them in the future.
      - cod1r 2y ago
        Thinkpad x1 carbon gen 10 lenovo
        trelane 2y ago
        I'm shocked to hear that Lenovo has buggy hardware. Shocked! Well, not that shocked. This tracks from what I've experienced and heard, though I don't think that one came with Linux. But I wasn't given a choice, unfortunately.
probablybetter 2y ago
The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing devices running multi-tasking OS'es on application processors, in my opinion. Current issues this article does not address that actually constitute large parts of the "mess" of Linux Audio: - channel mapping that is not transparent nor clearly assigned anywhere in userspace. (aka, why does my computer insist that my multi-input pro-audio interface is a surround-sound interface? I don't WANT high-pass-filters on the primary L/R pair of channels. I am not USING a subwoofer. WTF) - the lack of a STANDARD for channel-mapping, vs the Alsa config standards, /etc/asound.conf etc. - the lack of friendly nomenclature on hardware inputs/outputs for DAW software, whether on the ALSA layer, or some sound-server layer. (not to mention that ALSA calls an 8-channel audio-interface "4 stereo devices") - probably more, but I can't remember. My current audio production systems have the DAW software directly opening an ALSA device. I cannot listen to audio elsewhere until I quit my DAW. This works and I can set my latency as low as the hardware will allow it. this is the thing: more than about 10ms latency is unacceptable for audio recording in the multitrack fashion, as one does.
- miki123211 2y ago
  > The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. This is one of the major reasons why Linux accessibility sucks IMO. Audio is one thing that you need to "just work™" if you want to get accessibility right, as there's no way for a screen reader user to fix it without having working audio in the first place[1]. On Linux, it does not "just work", and different screen readers have different ideas on how they want audio to be handled. In particular, the terminal Speakup screen reader (with a softsynth) wants exclusive control of your device through ALSA IIRC, while the Orca screen reader for the GUI goes through Pulse. That makes it impossible to use both of them at the same time. [1] Well, you can sort of fix it by having a second machine and SSHing into the broken one, but that's not what I mean.
  - 2y ago
lynx23 2y ago
Well, we had a lot of layers in Linux Audio the last 30 years. But when PulseAudio was forced into the world by a c-section, with everyone in the LA community already knowing its a still-birth, I kind of lost trust in coordinated project creation. PA makes me so unhappy that I totally uninstall it whereever I see it. Good for me that I am just a console user, because the damn beast is all over the GUI space. Fact is, RT audio is hard, and the peoplebehind JACK have cared for the underlying problems for a long time already. Maybe PipeWire, but to be honest, it reminds me too much of PA. I guess I will stay with plain JACK and SuperCollider as my toolbelt, and not care about PA or PW. Like the grumpy old hacker I am.
probablybetter 2y ago
Am I the only one that sees unfriendly input/output channel names with Pipewire in client software? (Bitwig, Ardour, Reaper, more? I would like to see "Input 1" or "Channel 1" and not some strange ciphers when trying to assign things in a little dropdown selector in a DAW)
- krs_ 2y ago
  It seems to try to name the outputs based on the hardware name, but with multiple audio devices it can become quite confusing indeed. I've resorted to creating a wireplumber[1] config to rename things more reasonably and also disable a bunch of the inputs/outputs that I never use so they don't clutter up the lists. [1] https://pipewire.pages.freedesktop.org/wireplumber/index.html https://pipewire.pages.freedesktop.org/wireplumber/index.htm...
- trelane 2y ago
  This sounds (ha) like broken hardware.
deleted 2y ago
[deleted]
codedokode 2y ago
I don't really understand how was JACK supposed to be used. On Windows or Mac you typically run a DAW and load plugins into it. But on Linux the user is supposed to run every plugin as a separate application and connect them using JACK? Doesn't this mean there would be lot of context switches? Also, in a DAW you can save your configuration, but how do you do this with JACK and a bunch of independent applications? Also, given that Pulseadio and Pipewire both support ALSA clients, does it mean that the preferred API for applications should be ALSA? This way they can play sound on any system, even where there is no audio daemon.
moogly 2y ago
I want to move my DAW to Linux, but giving up TotalMix is quite a blow... Not sure how well the NI Native Access crap is working on WINE either. Does anyone know?
- chupasaurus 2y ago
  There's a page on WineHQ [0] with method to launch Native Access 2, works perfectly. [0] https://appdb.winehq.org/objectManager.php?sClass=version&iId=41820 https://appdb.winehq.org/objectManager.php?sClass=version&iI...

155 points by ruffyx64 2y ago

I remember there was oss and alsa. Then on top of that you had esd or artsd, with incompatible APIs and userland delays. Then at some point they were replaced with pulseaudio. I've just noticed now that pulseaudio is also replaced with pipewire in latest Ubuntu. That does not instill confidence in that they have any idea what they are doing. I remember that as far as on 2012 some Linux game ports from Steam (before Proton was a thing) failed to play sound. Other than that, it took them a decade to figure out that sound should switch to HDMI when it is plugged in. It may still require arcane config changes and may break down. I've opened the post to read about pipewire, and it seems that clicking an anchor does nothing. So it's not only sound they can't get right.

shmerl 2y ago
Don't worry, Pipewire is a very good development.
Cloudef 2y ago
Pipewire unifies all the apis, and is fully backward compatible. It has own API too, but you don't have to use it. You can write app using any of the apis, alsa, pulse, jack, and pipewire can work with it. You only need pipewire api if you need more control or pipe through video as well. JACK is very flexible approach to audio (think of unix pipes but audio) and this is what pipewire is inspired by, but targets the general desktop use and not just audio production as JACK does. Generally pipewire stays out of the way and works as pulseaudio replacement, but with the pipelines you can do a lot as a power user. Personally I think pipewire is one of the best things that has happened to linux, and since it shims all the previous audio apis instead of trying to tape the existing solutions into the package, it actually removes bloat from your system and you don't have to write weird libasound config files anymore.

shmerl 2y ago

> ALSA is the core layer of the Linux audio stack. It provides low-level audio hardware control, including drivers for sound cards and basic audio functionality. > ... > Ulike PuleAudio and JACK, PipeWire does not require ALSA on a system, in fact if ALSA is installed the output of ALSA is very likely pushed through PipeWire I don't get this part. If ALSA represents the kernel level hardware drivers for audio, how does Pipewire bypass it? Does it implement an alternative set of kernel drivers? I assumed Pipewire still relies on ALSA base.

bornfreddy 2y ago
This. Also, how does PulseAudio not support videoconferencing?
- shmerl 2y ago
  May be it's about a higher layer of ALSA API, not about actual hardware drivers.
  - exe34 2y ago
    yeah I think there are two ALSAs, one in the kernel as drivers and one as a userspace library.
- ruffyx64 2y ago
  Well. PulseAudio is a plain sound server. It does not handle video at all.
bigstrat2003 2y ago
I was also confused by this bit. If ALSA is part of the kernel, how can it not be installed?
- SSLy 2y ago
  The article doesn't note kernel-ALSA and the old userspace-ALSA libraries that apps use to push audio.

g15jv2dp 2y ago

I now have flashbacks to when I tried to get sound working on my Gentoo install 15 years ago. It seems that now everything has changed (wtf is pipewire) and still requires arcane knowledge to get everything working smoothly...

shmerl 2y ago
Pipewire is a major development that's especially important for Wayland desktop. It was hard to miss unless you haven't used Linux in a long time.
- nlpparty 2y ago
  I don't know what Pipewire is as well. I've used Linux daily for 10+ years, but I've never bothered to use Wayland.
  - shmerl 2y ago
    Well, time to move with the progress. I've been using KDE Wayland session for several years already.
    - exe34 2y ago
      nah I'm okay thanks. X11 still works flawlessly for me.
      - shmerl 2y ago
        The main issue is that X11 is an increasingly unmaintained case and all new development happens with Wayland anyway. So as long as you can deal with lack of support - I guess no need to move, but otherwise Wayland with KDE has been well usable for a while already.
        exe34 2y ago
        Yeah I'll move when I have hardware that really needs it. I use a 12 year old laptop.

Galicarnax 2y ago

The text has a strong GPT-ish flavor.

ssahoo 2y ago
Gpt is just emulating best writing quality. This article is very well written. If it was gpt generated, I'd be happy to read more like it.
- bowsamic 2y ago
  I genuinely think humans are going to degrade their writing style in order to sound less like an LLM
- pickledoyster 2y ago
  I'd argue gpt emulates the lowest (i.e. cheapest to mass produce) passable quality writing optimized for longest page time/views

kmarc 2y ago

I hear many complaining (even here) about "the mess" of linux audio. First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source. Second: linux is the only platform where everything works right now flawlessly for me: My Bose joins without any problems, switches to headset mode during zoom calls, switches back to high definition audio otherwise. I can select a different sink, even networked, whenever I want the output to appear on a different networked device. MacOS sometimes needs a reboot so that the bluetooth subsystem works, what the hell. And all this worked with PulseAudio, and now works with Pipewire, which is an even higher quality iteration of PA. I don't complain. I wish MacOS/Windows had such a versatile, configurable, but sanely-working-out-of-the-box audio system as an off-the-shelf Fedora, or even freaking Arch linux has. HTH [1]: https://blog.rtrace.io/images/linux-audio-stack-demystified/pulseaudio-architecture.png https://blog.rtrace.io/images/linux-audio-stack-demystified/...

bux93 2y ago
I'm sure the windows audio stack is many times more complex, and it's pretty opaque. OEMs also love to include all kinds of audio related bloatware, which makes getting audio hardware to work reliably(!) quite challenging. The HP laptop I'm typing this on has an "Intel microphone array" (just 2 mics) which has it's own intel drivers, but there's also some HP control panel, realtek and 'sound research' branded stuff, Fortemedia SAMsoft effects(?), Intel smart sound... If I'm recording seriously, I usually just go to the device manager (devmgmt.msc) and disable as much as I can and enable devices in a trial-and-error way to see what the minimum is to get audio to work again. Otherwise, all kinds of 'enhancements' end up in the audio path.
- hparadiz 2y ago
  If Windows could do what Linux can out of the box VoiceMeter would not exist.
  - 2y ago

sihox 2y ago

It's pretty nice article but for me - just for introductory purposes. It shows how sound and digital audio works and what basic libraries and tools we have in linux to deal with sound. But I'm still stupid when it comes to details and user interface tools. The article(s) I really love to see is, on one hand, more technically detail-specific and, on the other hand, broadly defining options I can have as an end user. I mean - from basic tools (CLI, GUI) that are available for simple purposes like volume control, stream selection, etc. to pro-audio, complex scenarios. For me it's too many tools and options I can use in linux for audio and this is the reason for being lost sometime. Of course for daily use I have pipewire with pulse, alsa and jack "plugins" which gives me seamless cooperation with lots of apps and controls but maybe I can get rid of some module or app...

Cloudef 2y ago

Pipewire has pretty much unified the userland linux audio stack (+ supports video as well as bonus). Kernel side it has always been alsa. There's TinyAlsa so you don't have to use libasound to interface with the kernel alsa. (userland alsa is quite PITA)

alexey-salmin 2y ago
> Kernel side it has always been alsa. Well you probably didn't mean it in a literal sense, but it was OSS up to kernel 2.4 and 2.6 had both OSS and ALSA

hcfman 2y ago

Beautiful work

laserbeam 2y ago

Here's my background 1. I have to modify my audio settings every time I start a call in Teams on Linux because it keeps losing my audio device. 2. In my audio settings UI, half the time I switch my devices the speaker test doesn't work. 3. In my audio settings UI, whenever I switch my mic I hear myself. The mic feedback only disappears 30 seconds after I close the settings UI. 4. My work headsets have a robotic sound (likely caused by an incorrect bitrate or buffer size). I can only use work bluetooth headsets via their dedicated dongle. This was my default experience on a popular debian based distro. And it mirrors the general experience I see online. Things are unstable and a mess. I started reading this article and it's embelished with phrases like: "is a professional-grade audio server", "widely used in professional audio production environments", and general language that sounds like a sales pitch. This does not fit with anything I'm familiar with. I would have preferred a neutral and semi technical approach, with 10% of the buzzwords. As written, I trust nothing.

n_plus_1_acc 2y ago
1. Is a known Problem with Teams
- laserbeam 2y ago
  Yeah, teams definitely shares in the blame there. That one hurts more and I blame both microsoft and linux.
  - pedrocr 2y ago
    The Teams web app works very well in Chrome. I only miss being able to set a custom background to my video and popping out presentations into their own window. It seems much lighter on resources too, maybe because Chrome does more of the video encoding or decoding using hardware.
juujian 2y ago
That would be your headset being in headset mode. I'm on Debian Testing, and I'm finally able to exit headset mode and use a high quality audio codec instead. I hope that's the direction Linux is heading.

gen2brain 2y ago

Whenever someone mentions Linux and Audio I always remember this image (made by Adobe I think) https://harmful.cat-v.org/software/operating-systems/linux/audio-mess.png https://harmful.cat-v.org/software/operating-systems/linux/a.... It is missing Pipewire but it should be easy to add a dozen of new lines. This is the reason why I simply use plain ALSA without any sound daemons.

pedrocr 2y ago
That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.
- creshal 2y ago
  Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.
  - gen2brain 2y ago
    And then there is Pipewire with PulseAudio plugin, and not to mention you can compile Pipewire with support for GStreamer, Jack, etc. I guess we can remove only the Arts and ESD daemons from that list, but the mess just adds up.
  - hawski 2y ago
    Aren't most of the libs you mentioned cross-platform or with a very specific use in mind which have direct analogues in Windows world?
    - creshal 2y ago
      Correct. You can draw just as messy a diagram for Windows. DirectSound versus OpenAL versus gstreamer(win32) versus jack(win32) versus XAudio2 versus DirectShow versus DirectMusic versus WDM Audio versus WASAPI versus UAA versus … If there's any difference it's that under Windows, the only debugging and error handling you have is "lol reinstall all drivers and codecs and pray".

poakjsn 2y ago

Linux distros would be best off lifting as much as possible from the Android Open Source Project, i.e. a professional and streamlined Linux-based system that actually works and isn't just a mishmash of incompatible, poorly designed hobbyist trash. The year of the Linux desktop never arrived but most of the world has Linux sitting in our palms. Let's build on that instead of the dead ends of Debian, Slackware, etc.

probablybetter 2y ago
wow. no. debian is the opposite of a dead end. now, ubuntu and lubuntu and xubuntu = i agree. android, however, is garbage. - it most certainly is not consistent across devices and editions - having to do phone-like-stuff on a desktop/laptop is painful - i hate Android. It's settings bother me the most. there is ZERO organization here! There are DARK patterns galore, it's built to dissuade you from doing anything serious. I can only take your comment as either a joke, or you literally only use a phone/tablet in life. news flash: Android audio is ALSA at it's core. Additionally: native Android audio is ultra-high-latency... completely unacceptable for pro-audio
curt15 2y ago
Hasn't Android audio always struggled with input latency?
- Ylpertnodi 2y ago
  I use several audio apps on Android, on a mid-low phone. The most intensive use comes from Cubase - Audio and synths, mixer, inputs and outputs, midi/ phone input program. After 30 years on Atari then windows I've had my ups and downs with the program, but I can easily say that my android version is a1 solid, connected to/ from my hardware synths

cod1r 2y ago

An issue I've experienced very often is that sometimes when my laptops goes to sleep and I wake it up, the speakers occasionally aren't switched to unless I restart pipewire. Same thing for headphones, sometimes when I plug them in, they aren't switched to unless I replug it in a couple of times. Might be hardware related but situations like this make me feel like I should just use linux for servers instead of for a personal computer.

trelane 2y ago
What version of Linux did your laptop ship with?
- cod1r 2y ago
  It had Fedora 36. So maybe Linux kernel 5.17 I have the latest kernel version now.
  - trelane 2y ago
    It's more about what distro the hardware vendor supports. What vendor and model laptop was it? I'll make a note to avoid them in the future.
    - cod1r 2y ago
      Thinkpad x1 carbon gen 10 lenovo
      - trelane 2y ago
        I'm shocked to hear that Lenovo has buggy hardware. Shocked! Well, not that shocked. This tracks from what I've experienced and heard, though I don't think that one came with Linux. But I wasn't given a choice, unfortunately.

probablybetter 2y ago

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing devices running multi-tasking OS'es on application processors, in my opinion. Current issues this article does not address that actually constitute large parts of the "mess" of Linux Audio: - channel mapping that is not transparent nor clearly assigned anywhere in userspace. (aka, why does my computer insist that my multi-input pro-audio interface is a surround-sound interface? I don't WANT high-pass-filters on the primary L/R pair of channels. I am not USING a subwoofer. WTF) - the lack of a STANDARD for channel-mapping, vs the Alsa config standards, /etc/asound.conf etc. - the lack of friendly nomenclature on hardware inputs/outputs for DAW software, whether on the ALSA layer, or some sound-server layer. (not to mention that ALSA calls an 8-channel audio-interface "4 stereo devices") - probably more, but I can't remember. My current audio production systems have the DAW software directly opening an ALSA device. I cannot listen to audio elsewhere until I quit my DAW. This works and I can set my latency as low as the hardware will allow it. this is the thing: more than about 10ms latency is unacceptable for audio recording in the multitrack fashion, as one does.

miki123211 2y ago
> The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. This is one of the major reasons why Linux accessibility sucks IMO. Audio is one thing that you need to "just work™" if you want to get accessibility right, as there's no way for a screen reader user to fix it without having working audio in the first place[1]. On Linux, it does not "just work", and different screen readers have different ideas on how they want audio to be handled. In particular, the terminal Speakup screen reader (with a softsynth) wants exclusive control of your device through ALSA IIRC, while the Orca screen reader for the GUI goes through Pulse. That makes it impossible to use both of them at the same time. [1] Well, you can sort of fix it by having a second machine and SSHing into the broken one, but that's not what I mean.
- 2y ago

lynx23 2y ago

Well, we had a lot of layers in Linux Audio the last 30 years. But when PulseAudio was forced into the world by a c-section, with everyone in the LA community already knowing its a still-birth, I kind of lost trust in coordinated project creation. PA makes me so unhappy that I totally uninstall it whereever I see it. Good for me that I am just a console user, because the damn beast is all over the GUI space. Fact is, RT audio is hard, and the peoplebehind JACK have cared for the underlying problems for a long time already. Maybe PipeWire, but to be honest, it reminds me too much of PA. I guess I will stay with plain JACK and SuperCollider as my toolbelt, and not care about PA or PW. Like the grumpy old hacker I am.

probablybetter 2y ago

Am I the only one that sees unfriendly input/output channel names with Pipewire in client software? (Bitwig, Ardour, Reaper, more? I would like to see "Input 1" or "Channel 1" and not some strange ciphers when trying to assign things in a little dropdown selector in a DAW)

krs_ 2y ago
It seems to try to name the outputs based on the hardware name, but with multiple audio devices it can become quite confusing indeed. I've resorted to creating a wireplumber[1] config to rename things more reasonably and also disable a bunch of the inputs/outputs that I never use so they don't clutter up the lists. [1] https://pipewire.pages.freedesktop.org/wireplumber/index.html https://pipewire.pages.freedesktop.org/wireplumber/index.htm...
trelane 2y ago
This sounds (ha) like broken hardware.

deleted 2y ago

[deleted]

codedokode 2y ago

I don't really understand how was JACK supposed to be used. On Windows or Mac you typically run a DAW and load plugins into it. But on Linux the user is supposed to run every plugin as a separate application and connect them using JACK? Doesn't this mean there would be lot of context switches? Also, in a DAW you can save your configuration, but how do you do this with JACK and a bunch of independent applications? Also, given that Pulseadio and Pipewire both support ALSA clients, does it mean that the preferred API for applications should be ALSA? This way they can play sound on any system, even where there is no audio daemon.

moogly 2y ago

I want to move my DAW to Linux, but giving up TotalMix is quite a blow... Not sure how well the NI Native Access crap is working on WINE either. Does anyone know?

chupasaurus 2y ago
There's a page on WineHQ [0] with method to launch Native Access 2, works perfectly. [0] https://appdb.winehq.org/objectManager.php?sClass=version&iId=41820 https://appdb.winehq.org/objectManager.php?sClass=version&iI...