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

[Christof Ressi]

Thanks for your replies!

> minor side-note: ESD is just a dummy.
> the Enlightened Sound Daemon died some decade ago.
> i'm not sure the Pd backend was ever used.
>
> it should be removed.

Yes, this is what I got as well.

> i never use portaudio, as it never really *worked* for me.

 From what I read below, what you actually mean is: "I never use 
portaudio's Jack implementation because it is too limited for my use 
cases". I can't believe that portaudio never worked for you in general...

> - in the JACK-graph, Pd now shows up as "PortAudio".
> audacity shows up as "PortAudio-71".
> unless of course i start audacity first, in which case audacity gets 
> the name "PortAudio" and Pd gets the name "PortAudio-67".
> (the numeric ID's are obviously generated (probably by JACK itself) to 
> make the names unique). thank you very much.

portaudio already has a Jack-specific API to set the client name: 
https://github.com/PortAudio/portaudio/blob/master/include/pa_jack.h

> - when using JACK via PortAudio, i can pick a destination where i want 
> to send audio to (and vice versa: a source to get audio from).
> that is: i can select my USB soundcard, or audacity (or whatever 
> application uses the "PortAudio" name...), or... all from within Pd.
> while this sounds cool at first glance, it really isn't.
> it means that *all* my channels go to a single peer.
> but how do i do any non-trivial routing: e.g. [adc~ 1 2] go to my 
> soundcard channels 17 & 18 (the headphones), while [adc~ 3 4] go to 
> JackTrip and all four channels go to Ardour?

Is this possible with Pd's implementation? How do you do this?

> i understand that PortAudio doesn't natively support setting up such 
> routing, we have specialized software for that (qJackCtl, patchage,...).
> but PortAudio is actually counterproductive, as it insists on 
> connecting to a peer - i cannot just pick "JACK - no automatic 
> connection".

Please make a feature request: https://github.com/PortAudio/portaudio/issues

> - oh, and while I *must* pick a peer, only peers that where available 
> when i started Pd show up.

Yes, it's a general problem with portaudio that you can't update the 
device list after calling Pa_Initialize(). There have been efforts to 
fix this (https://github.com/PortAudio/portaudio/tree/hotplug) but they 
seem to have lost momentum...

> - finally, when i start Pd with PortAudio, i get a lot of output on 
> the cmdline:

That's also an issue with some ASIO drivers. At least with ALSA we 
should check

1) does this still happen with the latest portaudio version?

2) does portaudio offer a way to disable this?

3) can we add a way to disable this?

Another solution would be to temporarily disable console output (unless 
"sys_verbose" is set). In fact, this could also be nice on Windows.

> - finally when Pd *initializes* PortAudio i get one or more very nasty 
> and loud click sounds (about 0dBFS). presumably this is because of 
> some samplerate switching (but i really don't know).

I never had this problem...

1) Is this really a problem with portaudio itself, i.e. does it happen 
with several apps that use portaudio?

2) If yes, does it still happen with the latest version?

3) Does it only happen with certain backends?

If this is really a portaudio issue, consider reporting it: 
https://github.com/PortAudio/portaudio/issues

---

Actually, I wouldn't have a problem with keeping our Jack backend. The 
code is rather short, readable and serves a clear purpose (more 
flexibility). To be fair, SuperCollider and Supernova also have a 
dedicated Jack backend, probably for the same reasons.

(On the long run, however, it would be better to make a PR to portaudio 
to implement the missing features as extensions, instead of every app 
rolling their own implementation.)

Our MMIO backend doesn't have any advantage over the portaudio 
implementation. It is just technical debt and I would love to see it gone.

The ESD backend is obsolete and can be removed.

I'm not sure about ALSA. Here would should really compare and see if 
there's a real showstopper in the portaudio implementation (that cannot 
be easily patched).

What about OSS? I understand that it's legacy, so maybe we can just use 
the portaudio implementation?

---

Even if we decide to keep portaudio, Jack and ALSA, that would be 3 
backends instead of 6! This would already be a big improvement.

To be clear: my concerns are really about maintainability and technical 
debt. For example, I regularly make experiments with the audio 
scheduling code. While I feel comfortable with the Jack and portaudio 
backend, I don't even dare to touch the other backends. Does anyone 
actually still understand all the code in s_audio_alsa.c, 
s_audio_alsamm.c, s_audio_mmio.c and s_audio_oss.c?

---

What about my proposition to include portaudio as a submodule, now that 
it's officially on GitHub?

Christof