On Thu, 20 Oct 2016, J. C. wrote:
The Arch Wiki suggests several alternatives, the old, the new and the new new
way. The latter being only suitable for JACKD with DBUS support, which I
don't have. As far as I'm aware, the DBUS version only works with X running,
which I don't want, all the time.
X is not needed, but in the end for DBUS to be useful, you do need some
kind of session manager such as screen if not using X. It is possible to
to use DBUS without, but all connected jackd/pulse/controllers need top
use the same DBUS instance and so would need a shell script that adds
environment info before running each one. Running screen from dbus-launch
is much easier. I have run pulse/jackdbus/jack_control in both of these
ways.
However, even though I run jackd2 - jackdbus and use tools like
jack_control to start and control jack, I do not use
module-jackdbus-detect to start the pulse-jack bridge... in fact at
session start, I unload it with:
pactl unload-module module-jackdbus-detect
I also run:
pactl unload-module module-udev-detect
and
pactl unload-module module-alsa-card
so that jack is the only (and therefore default) audio output pulse has. I
do this for two reasons. One is that I want jack to be default for
anything pulse gets. The second reason is that I have found that _any_
device pulse is attached to _will_ affect jack's stability and latency
abilities. Please note that the pulse to jack bridging module is presented
as an example, not a finished chunk of code.
So having run the three lines above, I now start jack:
jack_control ds $DRIVER dps capture none dps playback none
to clear out any old settings that might interfere with things.
jack_control dps device hw:${DEV} dps rate $RATE dps period $FRAME \
dps nperiods $PERIOD start
Actually starts jackdbus.
Then I do:
pactl load-module module-jack-sink client_name=PA-${DEV} channels=2
pactl load-module module-jack-source client_name=PA_${DEV} channels=2
I like being able to know from Pulse what the name of the device is, so I
add the devices name as part of it. I use zita-a2j/j2a to attach other
devices as well and use other PA/jack bridges to allow PA to see them but
add the connect=no so that PA doesn't connect them to the wrong device :P
I use:
jack_connect ${cname}-in:capture_1 PA_${cname}:front-left
jack_connect ${cname}-in:capture_2 PA_${cname}:front-right
etc. (it actually takes four lines for two in and two out) instead.
The script is run by a desktop file that points to it in
/etc/xdg/autostart/ or ~/.config/autostart/
jack_lsp -c after session start gives:
$ jack_lsp -c
system:capture_1
PA_M66:front-left
system:capture_2
PA_M66:front-right
system:capture_3
system:capture_4
system:capture_5
system:capture_6
system:capture_7
system:capture_8
system:capture_9
system:capture_10
system:capture_11
system:capture_12
system:playback_1
PA-M66:front-left
system:playback_2
PA-M66:front-right
system:playback_3
system:playback_4
system:playback_5
system:playback_6
system:playback_7
system:playback_8
system:playback_9
system:playback_10
PA-M66:front-left
system:playback_1
PA-M66:front-right
system:playback_2
PA_M66:front-left
system:capture_1
PA_M66:front-right
system:capture_2
PCH-in:capture_1
PA_PCH:front-left
PCH-in:capture_2
PA_PCH:front-right
PCH-out:playback_1
PA-PCH:front-left
PCH-out:playback_2
PA-PCH:front-right
PA-PCH:front-left
PCH-out:playback_1
PA-PCH:front-right
PCH-out:playback_2
PA_PCH:front-left
PCH-in:capture_1
PA_PCH:front-right
PCH-in:capture_2
AudioPCI-in:capture_1
PA_AudioPCI:front-left
AudioPCI-out:playback_1
PA-AudioPCI:front-left
AudioPCI-in:capture_2
PA_AudioPCI:front-right
AudioPCI-out:playback_2
PA-AudioPCI:front-right
PA-AudioPCI:front-left
AudioPCI-out:playback_1
PA-AudioPCI:front-right
AudioPCI-out:playback_2
PA_AudioPCI:front-left
AudioPCI-in:capture_1
PA_AudioPCI:front-right
AudioPCI-in:capture_2
a2j:Midi Through [14] (capture): Midi Through Port-0
a2j:Midi Through [14] (playback): Midi Through Port-0
a2j:Ensoniq AudioPCI [20] (capture): ES1370
a2j:Ensoniq AudioPCI [20] (playback): ES1370
D66 is a Delta 66
AudioPCI is an old ensoniq card
PCH is the internal card that would normally be disbaled.
My script looks for a file in ~/.config/ with what device I want to start
jack with (the M66 in this case) and then auto looks for any other audio
devices in the machines and connects them via zita-a2j. It is based very
much on http://jackaudio.org/downloads/adevices.sh for finding devices on
the system but does not bother with any sub devices besides 0... which is
all I need.
I start JACK through a self-written systemd service. Should I start
PulseAudio by default as well? Can such a shell script with Pulse settings be
executed at startup as well?
Pulse has to be running before the jackd start script with any of the
above things in it are run. To put it a better way both PA and jackd have
to be running before any bridging is done. I think systemd can be set to
not start a script till some other service is running.
All of the things I have used with jackdbus (2) should work just as well
with jackd1 except you would use a jackd commandline instead of
jack_command.
trouble spots:
whatever latency you set for jackd will affect PA. (the PA-jackd bridge
needs to be buffered to correct this) and so there are some PA
applications like Skype :P that just will not run if jackd has too low
of a latency. (Skype has been the one bad one for me 512/2 seems to work)
The other thing to be aware of is that not only does the cpu use of jackd
go up as the latency goes down, but so does PA's cpu use. In fact PA seems
to use twice as much as jackd. (in my case)
Not sure if any of this works for you or not...
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
