Talking about Jack

[Wapata]

Hi there !
I read that you plan to use Jack instead of Alsa.
I do think it's cool, but maybe not for what you think ;-)
Let's say you make it work with jack. You will have a very new cool feature : jack can talk through wifi / Ethernet / Internet ! So you can have Midi In and Out port linked to your Music computer that old all you midi devices, play with the patches, and then go out of you house with a setup ready to play music !

But I can say that I do have hard time to think how well it can work headless as I do think jack is not so easy to use with a computer and mouse...
Courage to you !

[albedozero]

Jack is in fact working on the SquishBox - you can use it by changing this line to just fluidsettings: - but it's going to remain as an option rather than a hard switch from ALSA. My reason for implementing it is that FluidSynth can run multi-channel outputs under JACK, so external LADSPA effects can be routed to from some MIDI channels and not others - nice when you're playing multiple instruments or backing tracks. The JACK daemon doesn't seem to play nice with the headphone jack on the Pi, however - it spits out a bunch of error messages and eventually segfaults - maybe something to do with this issue - so it doesn't work for headlesspi users and won't be a hard switch.

That's an interesting idea about using the network capability of JACK - agree it's probably tricky to do from command line! You could also run the GUI version of fluidpatcher directly on your music computer and have access to your MIDI devices that way 😉

[albedozero]

A quick update - I decided to make JACK the default driver for the SquishBox in the install script. Headless Pi still uses ALSA, and you can set your preferred driver by changing this line in squishboxconf.yaml.

[albedozero]

Some related comments from an email conversation, posting here for documentation (Thanks Kita Gábor for permission)

Hi Bill,
I reinstalled full raspbian, and fluidpatcher (curl -L git.io/squishbox | bash), because of wanted to try the rotary encoder version, and the ttymidi on uart. (And I saw, there is a newer fluidpatcher and I want to start a new, clean system)
Ttymidi is ok, I see the midi-in events on lcd (system menu/midi devices/midi monitor). But I have no sound :(
If I start the SquishBox.py manually (after service squishbox stop), I get trouble: (I use usb-midi again, ttymidi is not running) : "Failed to connect to Jack server"

root@realtimepi:/home/pi/SquishBox# apt-cache policy jackd1 jackd2

jackd1:
  Installed: (none)
  Candidate: 1:0.125.0-3
  Version table:
     1:0.125.0-3 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
jackd2:
  Installed: (none)
  Candidate: 1.9.12~dfsg-2
  Version table:
     1.9.12~dfsg-2 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
        100 /var/lib/dpkg/status

It looks like jackd2 didn't get installed for some reason. You can try just running the installer again or from the command line do: sudo apt-get install --no-install-recommends jackd2

Installed jackd2 solved the problem. I tried again from the beginning the whole install process but jackd2 was not installed again.

Aha! I figured out what's happening. When compiling fluidsynth from source, the script first grabs the build dependencies. If I haven't installed libjack-jackd2-dev, it defaults to using libjack-dev, which uninstalls jackd2.

[albedozero]

Fixed in a recent commit 😉

[albedozero]

With some trial-and-error I have been able to get JACK working with the headphone output on the Raspberry Pi. This is the /etc/jackdrc file that gets the job done:

/usr/bin/jackd --silent -R -d alsa -d plughw:Headphones -s -p 444 -n 3 -r 22050 -P -S

The plughw interface seems to be needed to convert the endian-ness of the audio samples (see below). Perhaps because of the extra processing time, JACK can't keep up at 44100 kHz and starts throwing xruns. I don't notice a huge difference in audio quality with the 22050kHz sample rate. The headphone output is low quality anyway - 11bits and distorts frequencies above 15kHz. The period size also has to be a large value - I'm using 444 because that's what the driver requests when you use plain old ALSA.

jackdmp output with -d hw:Headphones:

creating alsa driver ... hw:Headphones|-|444|3|22050|0|0|nomon|swmeter|soft-mode|16bit
configuring for 22050Hz, period = 444 frames (20.1 ms), buffer = 3 periods
ALSA: final selected sample format for playback: 16bit little-endian

jackdmp output with -d plughw:Headphones:

creating alsa driver ... plughw:Headphones|-|444|3|22050|0|0|nomon|swmeter|soft-mode|16bit
configuring for 22050Hz, period = 444 frames (20.1 ms), buffer = 3 periods
ALSA: final selected sample format for playback: 16bit big-endian

So, I think I will in fact make jack the default audio driver for both SquishBox and Headless Pi Synth - that way the headphone jack users will be able to use LADSPA effect routing and have access to realtime audio features, etc.

Thoughts? Anyone understand the endian-ness thing as it relates to the Pi's headphone jack?

[arretxe]

this provides some info (in spanish):
https://www.hispasonic.com/foros/dispositivos-alsa-default-hw-plughw/229653