[PD-dev] Why not use portaudio per default?

[Christof Ressi]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220121/83a0b0f9/attachment.htm>