Hi, Do you explicitly require PulseAudio? Just wondering, for example AV Linux uses JACK1 without PulseAudio at all, A combination of ALSA Loopback and an 'aloop-daemon' are auto-launched with JACK (via Qjackctl) and anything using JACK or ALSA (including browsers and media players etc.) is routed through the selected running JACK device, this eliminates the need for PulseAudio for anything except Skype which explicitly requires it now. Just curious if something like this would suit your needs, or whether you have a specific intended purpose for PulseAudio. Best Regards, Glen ----- Original Message ----- From: "J. C." &lt;julien(a)mail.upb.de&gt; To:"Linux-audio-users' mailinglist" &lt;linux-audio-user(a)lists.linuxaudio.org&gt; Cc: Sent:Thu, 20 Oct 2016 00:01:57 +0200 (CEST) Subject:[LAU] jackd1 and pulseaudio Hi list, I'm running a new Arch Linux system now and have come up against the Pulse/JACK dilemma. 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. Unfortunately, the Arch Wiki isn't accessible right now, so I can't post the proper link. But the described metho uses shell scripts setting PulseAudio sink and source modules to JACK and default sources and sinks to jack_in and jack_out respectively. 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? I'm sorry to raise the topic again, but I'm so very new to that snake pit. I'd be grateful for any tips, reading material for that situation. Best wishes, Jeanette -------- When you need someone, you just turn around and I will be there <3 _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

On Thu, 20 Oct 2016, J. C. wrote: 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. 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