-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jackdbus unexpectedly stopped working while jackd works with same settings #903
Comments
Same distro, same version, this time with an auditd log showing Jack2 deleting its own files in "/dev/shm", even though it keeps running: QjackCtl log:13:56:06.220 /usr/bin/jackd -S -dalsa -dhw:Generic -r48000 -p256 -n4 -Xseq terminal output:Cannot open shm segment (Invalid argument) auditd log:type=PATH msg=audit(1670594284.433:333): item=0 name="/dev/shm/" inode=1 dev=00:28 mode=041777 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root" |
@stefantalpalaru how this audit log relates to the original report? Despite its name, jack_control_client is part of https://github.com/jackaudio/jack-example-tools now and has nothing to do with the jack control api used by jackdbus and jackd for configuring jack server. OTOH "Cannot open shm segment (Invalid argument)" indicates that your setup probably has some other, unrelated to the original report, issue. |
@spencermp emerge --info indicates jack2 version 1.9.19, while you report it against version 1.9.21. Please clarify whether the issue you are experiencing is regression against 1.9.19 or not. It may be insightful to verify the xrun against kernel versions too. Please consider linking a gentoo bugtracker issue with more info on the issue. If newer jack2 is not stable actually, then it is gentoo stabilization issue too. As a side note, your emerge --info output indicates that you use installed with both classic and dbus use flags. Keep in mind that was never supported upstream and is discouraged in general. I see how it simplifies jackd vs jackdbus comparison tests. |
It shows a mechanism through which jackd unexpectedly stops working.
Must be started by QJackCtl, because none of my pre/post scripts use it. Anyway, it deletes the very important unix domain socket, while the Jack server keeps running.
No, that's just what Jack clients do when they cannot connect to that socket.
That might be it. My problems went away after disabling the "dbus" USE flag. |
Sorry about this, I had tried to update to jack 1.9.21 while writing up this bug report to see if it was an error with 1.9.19 in particular but no change there.
I enabled classic once jack_control / jackdbus started to have issues so that I could continue to use my audio, but just (as of writing this post) tested again disabling classic and the issues still persist on jackdbus.
Besides jack itself, I think the only things that would add latency here might be dbus itself or somehow the pam realtime module being messed up. I doubt either of these are the case, becasue ulimit -a shows everything being right and I've re-emerged the entire jack2 dependency tree (over 300 packages). |
It may be worth to compare jackd versions built with and without support for audio device reservation (over dbus). |
Describe the bug
I've been using jack since the start of 2022, and it's worked nearly flawlessly through cadence and jackdbus. Recently it's started to xrun on the same settings I've been using since I first set it up.
There are two ways to avoid the xruns: run jackdbus with a very high period and 4 nperiods OR use jackd with -p 128 and -n 3
Environment
Steps To Reproduce
While I use this bash script, I got the values from what I used in cadence and the output of
jack_control dp
Expected vs. actual behavior
Expected: jackdbus should work with the same settings as jackd
Actual: I get constant and grating xruns.
emerge --info jack2
Xrun:
jack_control dp
jack_control ep
The text was updated successfully, but these errors were encountered: