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

Roman Haefeli reduzent at gmail.com
Fri Jan 21 09:34:50 CET 2022


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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220121/cf4f4572/attachment-0001.sig>


More information about the Pd-dev mailing list