"Tim E. Real" <termtech(a)rogers.com> writes:
So there's no way to tell if a Jack system port
actually belongs to (our own)
ALSA client?
If a2jmidid is used in dbus mode, you can map ports through the dbus calls:
<method name="map_alsa_to_jack_port">
<arg name="alsa_client_id" type="u" direction="in"
/>
<arg name="alsa_port_id" type="u" direction="in"
/>
<arg name="map_playback" type="b" direction="in"
/>
<arg name="jack_port_name" type="s" direction="out"
/>
</method>
<method name="map_jack_port_to_alsa">
<arg name="jack_port_name" type="s" direction="in"
/>
<arg name="alsa_client_id" type="u" direction="out"
/>
<arg name="alsa_port_id" type="u" direction="out"
/>
<arg name="alsa_client_name" type="s"
direction="out" />
<arg name="alsa_port_name" type="s" direction="out"
/>
</method>
lpatchage and ladish use this to display one box per alsa client and
to merge mapped alsamidi ports and jack audio ports into same box given
that jack client name and alsa client name matches.
Of course this is a workaround for subopitmal jack API. Other workaround
is the alias mechanism. Hopefully one day jack API itsell will get
fixed, in 2020 maybe :]
As side note, a2jmidid and its jack internal client incarnations
should use multiple clients. And then the client autorenames hit the
fan.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>