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
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
