I've gotten a bit exotic with multiple machines. On the machine with the good soundcard connected to the good speakers I have a pulse over jack setup. Mostly the same as it has been for a good while, except jackd2 now (jackdbus). Setup as follows based on #3 of the guide.
http://jackaudio.org/faq/pulseaudio_and_jack.html
https://github.com/jackaudio/jackaudio. ... ulseOnJack
It is quirky for non-tech types. I have to run a script after start up, then restart pulseaudio.
FILE: myjackcontrol.sh
Code: Select all
#!/bin/bash
#jack_control start
jack_control ds alsa
jack_control eps realtime false
jack_control dps device hw:1
jack_control dps rate 48000
jack_control dps rate 48000
jack_control dps nperiods 3
jack_control dps period 512
So...
$ ./myjackcontrol.sh
$ jack_control start
$ pulseaudio --kill
$ pulseaudio --start
What I do every time I start X. And it works. Relative to debian stable (jessie), I have the following modifications (additions) from the defaults.
FILE: /etc/pulse/client.conf
FILE: /etc/pulse/default.pa
Code: Select all
load-module module-native-protocol-tcp auth-ip-acl=192.168.2.0/24;127.0.0.1
set-default-sink jack_out
set-default-source jack_in
FILE; /etc/pulse/daemon.conf
Code: Select all
default-sample-format = s16le
default-sample-rate = 48000
realtime-scheduling = no
exit-idle-time = -1
On the machine with the pulse over jack setup, with the exception of the user who starts pulseaudio. I use multiple users, one for networking, one for web browsing, one for media creation, and on and on. It helps me keep individual bash_history, browser logins, or just makes it easier to see which user (process) is hogging all the drive space. $(xhost local:) if you want to do that and share the X session.
FILE: $HOME/.config/pulse/client.conf
For all users.
FILE: $HOME/.asoundrc
Code: Select all
ctl.pulse { type pulse fallback sysdefault }
pcm.pulse { type pulse fallback sysdefault }
ctl.!default { type pulse fallback sysdefault }
pcm.!default { type pulse fallback sysdefault }
For the remote machine using pulseaudio over the network, change the 127.0.0.1 (aka localhost) to the ip of the pulseaudio machine 192.168.2.1 in my case.
FILE: $HOME/.config/pulse/client.conf
Which is minimal effort for all the client users / machines. A neat trick I recently learned is using alsa's loopback device to run jack on the remote machine and then send that to pulse on the server machine. Or to your local machines soundcard (lower latency) while still having a remote pulse setup.
$ sudo modprobe -r snd-aloop
$ sudo modprobe snd-aloop pcm_substreams=2 enable=1
start jackd using the loopback device
$ jackd -r -m -t 10000 -d alsa -d hw:Loopback -P -o 2 -r 44100 -S -s -m
send jackd to pulse on the "other" computer.
$ alsaloop -C hw:Loopback,1,0 -P pulse
send jackd to the local soundcard.
$ alsa_in -j hw:Loopback -d hw:1
$ alsa_out -j hw:Loopback -d hw:1
And then do the usual jackd stuff. As a side note when starting rosegarden the alsaloop process dies, just restart it after rosegarden starts. And sometimes the sound routing fails but jackd and everything is still active and appearing to work. Just restart it all again to recover with actual sound. Most of my machines are low specifications so YMMV.
$ fluidsynth -a jack -g 1.5 -j -l -m alsa_seq -K 0 /usr/share/sounds/sf2/FluidR3_GM.sf2
$ vkeybd --octave 8 --channel 0 --device alsa
$ qjackctl
Note that I'm doing that with jack1 on the remote (local) to me machine and pulse over jack2 on the host machine. And I can have the local soundcard and the pulse host outputting sound at the same time. Each layer does add latency, so midi notes have an audible echo with alsa_out and alsaloop at the same time, probably close to 30ms if I were to measure it. The one advantage of a route like this is that the host machine does all the heavy lifting of running pulseaudio over jackd, plus other stuff like a 30 band EQ from the calfjackhost plugins. With all that processing happening on the host machine. So when you're local machine gets under load, the audio remains relatively unaffected. And you can get a couple more fps in games on the local machine. Another caveat is that you need to keep the system clocks relatively in sync.
$ sudo ntpdate pool.ntp.org
If you're not running a ntpd that does that on the regular.
