> Easily, reliably, and quickly playing audio is table stakes for Windows and Mac OS. They've been doing it for years. But instead of improving one or two audio APIs, on Linux it is time for a new audio server that will, but doesn't, solve all of the problems of every predecessor.
I mean, I have currently 5 soundcards on my desktop computer, 1 pro over PCIe, 2 pro over USB, 1 standard HD Audio and 1 output in my screen's HDMI, and I can assure you that even on windows it's definitely not a smooth ride between WASAPI, ASIO, MME, WDMKS... things crash or get stuck routinely, and I sometimes get random loud buzzes or no sound until I reboot. With my band we had tons of issues with a M-Audio card on windows fixating itself on the wrong sampling rate as soon as a desktop music playing was launched (this includes web browsers), entirely preventing playback on Ableton Live for instance.
It's barely better on macOS, e.g. look at that shit: https://github.com/OSSIA/score/issues/778. macOS also sacrifices some low-latency when comparing the same hardware on it versus Linux (with raw ALSA or JACK) and Windows with ASIO.
I think the guy with 5 sound cards might be the exception that proves the rule - the conversation was about playing back audio from the browser not which OS starts to fall apart when you need a DAW for your band.
> the conversation was about playing back audio from the browser
well, no, the web audio API & stuff is explicitly being sold as something that will be equal in capability to other solutions, so definitely things used for pro audio.
Even quite modest normal setups will have several input or output devices. Just on my laptop I have hdmi audio, built in speaker and mic, USB headset, bluetooth headset and remote audio from an RDP session.
What exists as far as open source digital audio interfaces? Meaning only digital i/o — no analog.
It seems like a relatively contained problem to take multiple streams of PCM audio into a computer, locked to word clock. Then the hard, fiddly aspects of analog design can be left to high-quality outboard converters which speak MADI or whatever.
I say "contained" because I don't want to minimize the difficulty of getting such a design right, but it seems like you only have to get it right once.
What I'm looking for is a way to hook up any converter which outputs via a standard digital audio protocol (SPIDF, AES/EBU, ADAT lightpipe, etc.).
Then we don't need a USB driver for each converter! We only need one USB driver, for the digital i/o interface. And we can polish the driver for that one interface until it's actually reliable, instead of relying on the sketchy one-off driver for this year's soon-to-be-obsolete USB audio interface.
If I'm not mistaken the underlying transport protocol is the same for all of those - you can get a coaxial to XLR to get S/PDIF into an AES port or a coaxial to TOSLink converter to get S/PDIF data into an ADAT port.
In terms of i/o capability, the specs of the Madiface XT would work well for the purposes I'm proposing.
But the point is that I want open source drivers, and open source hardware! I don't want to depend on the health and the priorities of a commercial entity. I want to be able to inspect the driver software and contribute towards perfecting it!
Compared to, say, GPUs, the needs of multichannel digital audio i/o are modest and not changing very much over time.
> If I'm not mistaken the underlying transport protocol
Some quick usage of Wikipedia suggest that you are, sadly, mistaken. ADAT lightpipe seems to use a completely different protocol (more capable?), and while S/PDIF and AES/EBU use quite similar protocols, they differ in impedance and max and min voltages, so I'm guessing that directly electrically connecting the two controllers is a bad idea for both the controller and the data.
It doesn't matter for the purposes I'm investigating. So long as we can get the bits out of the wire and into open source software, we can make sense of them.
(Licensing could be a concern though if ADAT lightpipe is proprietary — I'm not clear on that. But then we could just use other open protocols instead.)
I only have a "main" soundcard (the PCIe one) - HD audio and HDMI thing are unused 99% of the time, but if you have a computer more recent than 2007 you have them. The two USB soundcards are temporary and here currently because I need to test stuff for the sequencer I'm developing (https://ossia.io)
I mean, I have currently 5 soundcards on my desktop computer, 1 pro over PCIe, 2 pro over USB, 1 standard HD Audio and 1 output in my screen's HDMI, and I can assure you that even on windows it's definitely not a smooth ride between WASAPI, ASIO, MME, WDMKS... things crash or get stuck routinely, and I sometimes get random loud buzzes or no sound until I reboot. With my band we had tons of issues with a M-Audio card on windows fixating itself on the wrong sampling rate as soon as a desktop music playing was launched (this includes web browsers), entirely preventing playback on Ableton Live for instance.
It's barely better on macOS, e.g. look at that shit: https://github.com/OSSIA/score/issues/778. macOS also sacrifices some low-latency when comparing the same hardware on it versus Linux (with raw ALSA or JACK) and Windows with ASIO.