Hi,
here's a question that has been bugging me for quite a while: Why do we keep all those individual audio backends instead of just using portaudio everywhere? Are there any other reasons *besides* backwards compatibility with existing setups (saved preferences)?
Currently we have the following backend (excluding the dummy backends):
ALSA: s_audio_alsa.c
ESD: s_audio_esd.c
Jack: s_audio_jack.c
MMIO: s_audio_mmio.c
OSS: s_audio_oss.c
portaudio: s_audio_pa.c
---
Portaudio already supports all relevant audio backends (https://github.com/PortAudio/portaudio/tree/master/src/hostapi), so I don't see why we would have to provide our own implementations at all. It is just a big maintainance cost. Everytime we change something in the scheduling code, we have to make sure not to break any of those custom backends. Another advantage of using the portaudio "backend" is that you can always choose between the callback scheduler and the polling scheduler.
I acknowledge that removing backends could break existing setups (because of saved audio preferences). Alternatively, we might actually keep them around for some time but hide them from the GUI. Either way, we could post a warning whenever we encounter an "audioapi" value other than "API_PORTAUDIO" in the preferences or any of the "-alsa", "-mmio", "-jack", "-oss" command line flags. So in practice people would just need to go to the audio settings, select the device again and save it.
---
As a first step, we might compare our backend implementations with the portaudio implementations and see if there are any shortcomings.
Regarding MMIO: the portaudio implementation works fine (tested with 1024 buffer size + 20 ms latency, both with and without "callbacks"). Generally, MMIO is very outdated and shouldn't be used in the first place. On Windows 7 and above, the best choice - besides ASIO - would be WASAPI.
ESD (https://en.wikipedia.org/wiki/Enlightened_Sound_Daemon) is obsolete and can probably removed. Quote from "s_stuff.h": /*noideawhatthiswas,probablygonenow*/
This would only leave us with ALSA, Jack and OSS. To make comparisons, we would need to compile portaudio with ALSA, Jack and OSS support. Note that our portaudio folder doesn't include the "oss" and "jack" source folders.
---
BTW, portaudio is now officially hosted on GitHub (https://github.com/PortAudio/portaudio) and development seems pretty active. In April 2021 they have finally released a new version (0.19.7) after 5 years! There is even a recent PR for pulseaudio support: https://github.com/PortAudio/portaudio/pull/336.
This leads me to another question: should we include portaudio as a submodule? This would make it much easier to get the latest changes from upstream or send our own changes to upstream.
Christof