Is there anyone who has written a systemd service that can actually start JACK? I have been through this as a system service, a user service, a system service ran as a user, with the service calling jack directly, and running a messy collection of scripts.
The only thing I’ve ever got to work reliably is script on top of script where there is some loop where I keep trying to get the service started and it just pounds on it until the damn thing works.
Does this not seem like it should be the way to start this service? What am I missing?
I have a USB soundcard, the internal soundcard is disabled. I use the pulse-jack bridge. I never have trouble starting JACK manually, it’s always during system startup. My JACK is the jack2 package in Arch Linux.
I am much obliged for the link, however it doesn’t work.
As usual, the service dies immediately.
$ systemctl --user status jack2
● jack2.service - JACK server using .conf profile
Loaded: loaded (/home/luke/.config/systemd/user/jack2.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2020-05-10 11:53:34 EDT; 1min 58s ago
Docs: man:jackd(1)
Process: 1072 ExecStart=/usr/bin/jackd -dalsa -dhw:USB,0 -r48000 -p1024 -n2 -S -P -o2 -zs (code=exited, status=255/EXCEPTION)
Main PID: 1072 (code=exited, status=255/EXCEPTION)
May 10 11:53:33 ultra-arikui jackd[1084]: Output information may be incomplete.
May 10 11:53:34 ultra-arikui jackd[1072]: ATTENTION: The playback device "hw:USB,0" is already in use. Please stop the application using it and run JACK again
May 10 11:53:34 ultra-arikui jackd[1072]: Released audio card Audio3
May 10 11:53:34 ultra-arikui jackd[1072]: audio_reservation_finish
May 10 11:53:34 ultra-arikui jackd[1072]: Cannot initialize driver
May 10 11:53:34 ultra-arikui jackd[1072]: JackServer::Open failed with -1
May 10 11:53:34 ultra-arikui jackd[1072]: Failed to open server
May 10 11:53:34 ultra-arikui systemd[1066]: jack2.service: Main process exited, code=exited, status=255/EXCEPTION
May 10 11:53:34 ultra-arikui systemd[1066]: jack2.service: Failed with result 'exit-code'.
May 10 11:53:34 ultra-arikui systemd[1066]: Failed to start JACK server using .conf profile.
And again, as usual, if you go poke at it yourself, it will work:
$ systemctl --user start jack2
$ systemctl --user status jack2
● jack2.service - JACK server using .conf profile
Loaded: loaded (/home/luke/.config/systemd/user/jack2.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-05-10 11:56:25 EDT; 2s ago
Docs: man:jackd(1)
Main PID: 2189 (jackd)
CGroup: /user.slice/user-1000.slice/user@1000.service/jack2.service
└─2189 /usr/bin/jackd -dalsa -dhw:USB,0 -r48000 -p1024 -n2 -S -P -o2 -zs
May 10 11:56:24 ultra-arikui jackd[2189]: under certain conditions; see the file COPYING for details
May 10 11:56:24 ultra-arikui jackd[2189]: JACK server starting in realtime mode with priority 10
May 10 11:56:24 ultra-arikui jackd[2189]: self-connect-mode is "Don't restrict self connect requests"
May 10 11:56:24 ultra-arikui jackd[2189]: audio_reservation_init
May 10 11:56:24 ultra-arikui jackd[2189]: Acquire audio card Audio3
May 10 11:56:24 ultra-arikui jackd[2189]: creating alsa driver ... hw:USB,0|-|1024|2|48000|0|2|nomon|swmeter|-|16bit
May 10 11:56:24 ultra-arikui jackd[2189]: configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
May 10 11:56:24 ultra-arikui jackd[2189]: ALSA: final selected sample format for playback: 32bit integer little-endian
May 10 11:56:24 ultra-arikui jackd[2189]: ALSA: use 2 periods for playback
May 10 11:56:25 ultra-arikui systemd[1066]: Started JACK server using .conf profile.
As much as I love working with JACK getting it to start is a real pain that apparently no one has solved. I’m not sure why this is so difficult.
Your sound card is being used by something (maybe pulseaudio) and that is why jack can’t start. It can’t get access to the card. Adding a 60 second (or longer) delay to jack startup might help. Another possibility is not use systemd but add jack startup to the login scripts of your desktop.
I’m sorry, I think the point is getting muddied. I am not having trouble reading the error message, and, like I said, I can pile scripts on top of scripts to force this to work. I just think that a solution should be found where every single person doesn’t need to spend days scripting and troubleshooting to get audio working on their machine. Does no one else feel this way?
If you disable pulseaudio, like systemctl stop pulseaudio && systemctl disable pulseaudio , you should be able to get it to work.
Or maybe you can use an ExecStartPre to stop pulseaudio before starting jack.
I could be wrong but I don’t think that many people use systemd to start jack. Most probably use QJackCtl or start it directly from the ardour launch screen.
Because of the way jackd shares memory between applications it has to run as your user account, and you need to have an active session. I am not sure how systemd can be used to start per user services, but that is what you would need, a way to start jackd after your user session has started.
Using desktop environment autostart as suggested by mhartzel would probably be easier and more reliable. Is there some particular reason you really want to use systemd?
There are a couple of people who have gotten jackd to start reliably with systemd, but that was on headless systems, the goal was to have a network server which could accept netjack connections after power on without requiring any intervention. I believe the solution involved getting a dbus session created, but that was for non-interactive use, if you tried using that solution I’m not sure how you could then get your interactive login to use the same dbus session which was already created. Seems like a lot more trouble than it is worth.
Are you also starting pulseaudio jack-sink automatically so that other desktop applications can use jackd for system sound output?
Peder: Thanks for the input. While pulseaudio is not a service, in that vein I had written scripts to prevent pulseaudio from respawning, killing it, starting jack, then start pulseaudio again, but it also fails without complicated layers of scripts and retries.
Chris: Yes! systemd has services that run as a user. I am doing this. I think it’s a timing problem really.
I’m really trolling around to see if anyone has solved this already, and no worries if not. I’m also asking in the systemd subreddit.
I’d really like to solve this because I’d like to make starting JACK on a machine and knowing it will start reliably is important for both making my life easier and it being more accepted as a pro audio solution. Imagine if people started ALSA with a million different scripts (not that that makes sense)? No one would accept that situation.
Linux audio may or may not be more complex than any other OSes solution but it really doesn’t matter if it works reliably and any complexity is not unnecessarily exposed.
I think a solid systemd service to start JACK would be a boon to anyone who seriously uses it and would be portable between different desktop environments.
If that’s not the case I don’t understand the intention. I’m starting my studio, where in any stretch of the imagination my network shares are come up mounted, ardour is kicked off automatically at boot and ready to go with a template loaded up for me, we are ready to record, but no. JACK didn’t feel like starting this time, especially because someone is looking, when it worked the previous 15.
I, in all due respect, feel this is a deficiency. Regardless of which this may still very well be the best solution. I have been invested in Linux audio for so long I am clueless about the other platforms. I have a hard time accepting they could be this flexible as my set up now, though.
I hope this does not come across as rude. Thanks for your time.
It’s quite simple to repeat this: when I wrote JACK, i never envisaged it as a system service. That’s all. It’s a per-user tool that you may need/want to stop/start/reconfigure many different times during a given login (or system uptime).
That could be a mistake. It could be that most people’s use of JACK doesn’t match that. But that seemed like an entirely reasonable model of use when JACK was created.
In addition, we recomemnd that most people don’t even use JACK at this point, unless they specifically need to (i.e. sharing the audio interface among several pro-audio/music creation applications and/or routing audio/MIDI between applications).
The majority of Ardour users do not need to use JACK and using it adds complications especially for new users and/or those with complex system configurations. The ALSA backend is generally a better choice.
Or you add QJackCtl to the autostart, have it start jack on launch and use the “Execute sctipt after startup” option to launch ardour.
The thing is to make sure nothing is playing sounds through the interface when jack is starting.
So make sure any Desktop Environment sounds are turned off, so it’s not playing a login fanfare just as jack tries to take control of the interface, and that you don’t have anything else that’s autostarting and is trying to play things.
I usually compile jack myself and make sure to disable the dbus interface.
Maybe that’s why I’ve never had any problems stating jack; unless I’ve done something stupid like playing a YouTube video in Firefox, though pulseaudio, when starting it.
Or maybe there’s something particular about Arch which makes it problematic for you.
I’m using openSUSE and Ubuntu, with XFCE as my DE.
I assume you know what you’re doing with the -S -P -o2 -zs flags. And that you deliberately are using n2 instead of the recommended n3 with your USB interface.
Heads up: these are options for the ALSA backend (not jackd)
-S, --shorts
Try to configure card for 16-bit samples first, only trying 32-bits if unsuccessful.
Default is to prefer 32-bit samples
-P, --playback [ name ]
Provide only playback ports, unless combined with -D or -C. Optionally set playback device nam
This not to be confused with passing them directly to jack (before -dalsa) where it’d be --sync (jack2 only) and --realtime-priority respectively.
Using shorts dithering seems intentional, probably due to a cheap soundcard that does not support 24 or 32bit data DMA.
I had written up some replies to everyone, but I feel like I’ve wasted enough of your time. I just really enjoy using this software, felt it has the most terrific and flexible design, and was looking for ways to get it running as reliably and portably as possible. If it could be started consistently enough that people would forget it exists, you’d be a fool to do pro audio work without it.
From an uneducated and completely naive perspective I think that JACK as a persistent service sounds ideal but if there is no interest in that from the developers then I won’t mention it any more. I already have ways to make JACK work 19 out of 20 times.
If you want to find out if the jackd developers have any interest then you should ask on the jack-devel mailing list. Paul is the former developer of jackd v1, but retired from that several years ago, and has been quite explicit that his opinion is that almost all Ardour users should just use the Ardour ALSA backend. Since this is the ardour forum and has no relation to the current jackd maintainer(s) trying to determine if there is any interest from jackd developers by asking on the ardour forum is not a fruitful path.