Hi
I tend to side with IOhannes here. I find the flexibility of the current JACK backend with the options -nojackconnect, -jackname, -inchannels, -outchannels quite valuable. I don't know what portaudio offers in comparison, but one would expect a general purpose audio API covering a variety of audio backends cannot specialize in each them.
As IOhannes already mentioned, I find the aggressive probing annoying. Audacity, for instance, doesn't even show up in JACK unless it is playing. When the playing stops, it disappears again. That makes it unnecessarily complicated to use except for the most simple cases. I wouldn't want to have to reconnect Pd after each time I turn DSP off.
Maybe I'm suffering FUD and my concerns are unsubstantiated. But then again, why relying on portaudio not breaking things when the current JACK implementation seems quite mature now?
Roman
On Fri, 2022-01-21 at 08:49 +0100, IOhannes m zmoelnig wrote:
i'll start answering before reading your entire message, so...
On 1/21/22 02:58, Christof Ressi wrote:
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
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.
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
i never use portaudio, as it never really *worked* for me. and JACK always worked for me. i see little merit in abandoning a working system in favour of fixing a non-working system.
more importantly: i'm using JACK as the main audio provider for my system. so the relevant part for me is how portaudio deals with JACK.
and here the trouble starts. to name but the first that come to my mind:
- 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.
- 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? 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".
- oh, and while I *must* pick a peer, only peers that where
available when i started Pd show up.
- finally, when i start Pd with PortAudio, i get a lot of output on
the cmdline:
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ALSA lib pcm_a52.c:1001:(_snd_pcm_a52_open) a52 is only for playback ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card' ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'it seems that whatever these printouts mean to tell me is rather harmless, but even so it is a lot of noise that i would rather not see.
- 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).
so the question is: can we fix these problems within Pd? afaict the answer is "no". my reference PortAudio application is audacity, which shows exactly *all* of the problems described above.
for me this is really enough to not pick PortAudio. (esp. since the existing JACK backend does not have any of these problems). i guess most people do not hear the click sound when initializing PortAudio (it makes it unusable in any live performance context; and there are *some* applications that only offer PortAudio as a backend that i would think have widespread use). and probably many people do not care about the routing issues, because they only ever do trivial routing.
but for me, it's a no-go.
gmadrs IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev