5 ms·

Good news to see work being done on the Linux-audio 'bottleneck'. I miss the ease-of-use and options available on other platforms (I left behind).

PaulDavisThe1st 7y ago
Trust me, the device audio/MIDI APIs are not the bottleneck. Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison. I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions. Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.
- RossBencina 7y ago
  I don't know whether the audio APIs are a bottleneck for programmers, but for me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting _average users_ to be able to do prosumer audio on Linux. With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem. As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem. [1] More specifically: resolving misconfiguration. [2] By this I mean a solution that works by design, not by luck.
  - cycloptic 7y ago
    Pipewire is probably not going to make your ALSA configuration issues go away. It's built on top of ALSA just like everything else. What it might do is make it easier to have low-latency audio across multiple devices. And it may save you some of the hassle of having to configure JACK and LADISH. Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.
    - RossBencina 7y ago
      Thanks for offering to help. I'm okay at the moment. I was referring to other users reporting issues that turn out to be ALSA configuration problems (e.g. on the PortAudio mailing list). Sidenote: the fact that someone needs to offer help is part of the issue that I'm pointing at. Once a driver is installed on Windows or Mac OS I've never heard of someone experiencing misconfiguration of the audio subsystem as a whole. The main ALSA misconfiguration issue I've personally encountered were not related to the audio drivers per-se, but to codec mixer configuration. It was on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data sheet to work out how to set all the ALSA mixer flags and parameters correctly to get audio routing to send a signal to the output jack.
      - cycloptic 7y ago
        I'm not sure what larger issue you're pointing at and I don't think it makes sense to chalk this up to anything else; no sound server can magically figure out how to read that data sheet either. A random userspace daemon (that is optional) is just not the right place to put a fix for that. The burden for a fix likely falls on your distro to ship the correct udev rules, but figuring out what those are for all variations of hardware that use that driver is another story. With that who knows, the Windows and Mac driver could actually be doing something strange by default that just happens to work for most users, but isn't worth replicating if someone writing udev rules decides they want to do the "right" thing. See where I'm going with this? It's not just a quick fix, and I don't even know if it's the right one. Some other distro somewhere might even have a different way to do it. If you're really interested to make progress on this, you'll have to ask your distro's audio maintainers.

PaulDavisThe1st 7y ago

Trust me, the device audio/MIDI APIs are not the bottleneck. Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison. I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions. Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.

RossBencina 7y ago
I don't know whether the audio APIs are a bottleneck for programmers, but for me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting _average users_ to be able to do prosumer audio on Linux. With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem. As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem. [1] More specifically: resolving misconfiguration. [2] By this I mean a solution that works by design, not by luck.
- cycloptic 7y ago
  Pipewire is probably not going to make your ALSA configuration issues go away. It's built on top of ALSA just like everything else. What it might do is make it easier to have low-latency audio across multiple devices. And it may save you some of the hassle of having to configure JACK and LADISH. Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.
  - RossBencina 7y ago
    Thanks for offering to help. I'm okay at the moment. I was referring to other users reporting issues that turn out to be ALSA configuration problems (e.g. on the PortAudio mailing list). Sidenote: the fact that someone needs to offer help is part of the issue that I'm pointing at. Once a driver is installed on Windows or Mac OS I've never heard of someone experiencing misconfiguration of the audio subsystem as a whole. The main ALSA misconfiguration issue I've personally encountered were not related to the audio drivers per-se, but to codec mixer configuration. It was on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data sheet to work out how to set all the ALSA mixer flags and parameters correctly to get audio routing to send a signal to the output jack.
    - cycloptic 7y ago
      I'm not sure what larger issue you're pointing at and I don't think it makes sense to chalk this up to anything else; no sound server can magically figure out how to read that data sheet either. A random userspace daemon (that is optional) is just not the right place to put a fix for that. The burden for a fix likely falls on your distro to ship the correct udev rules, but figuring out what those are for all variations of hardware that use that driver is another story. With that who knows, the Windows and Mac driver could actually be doing something strange by default that just happens to work for most users, but isn't worth replicating if someone writing udev rules decides they want to do the "right" thing. See where I'm going with this? It's not just a quick fix, and I don't even know if it's the right one. Some other distro somewhere might even have a different way to do it. If you're really interested to make progress on this, you'll have to ask your distro's audio maintainers.