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