23 Jan
2024
23 Jan
'24
8:35 p.m.
Hello,
I'm "suddenly" (after a couple months of disuse) unable to start jack
in real-time mode, making ardour unable to take advantage of it. I've
had more or less the same setup for more than 10 years, so I've really
forgotten if there is anything else than the below that I could
investigate.
Tue Jan 23 20:21:51 2024: Starting jack server...
Tue Jan 23 20:21:51 2024: JACK server starting in realtime mode with priority 10
Tue Jan 23 20:21:51 2024: self-connect-mode is "Don't restrict self
connect requests"
Tue Jan 23 20:21:51 2024: Acquired audio card Audio2
Tue Jan 23 20:21:51 2024: creating alsa driver ...
hw:MobilePre|hw:MobilePre|128|3|48000|0|0|nomon|swmeter|-|32bit
Tue Jan 23 20:21:51 2024: configuring for 48000Hz, period = 128 frames
(2.7 ms), buffer = 3 periods
Tue Jan 23 20:21:51 2024: ALSA: final selected sample format for
capture: 16bit little-endian
Tue Jan 23 20:21:51 2024: ALSA: use 3 periods for capture
Tue Jan 23 20:21:51 2024: ALSA: final selected sample format for
playback: 16bit little-endian
Tue Jan 23 20:21:51 2024: ALSA: use 3 periods for playback
Tue Jan 23 20:21:51 2024: ERROR: Cannot use real-time scheduling
(RR/10) (1: Operation not permitted)
Tue Jan 23 20:21:51 2024: ERROR: AcquireSelfRealTime error
# ls -l /dev/rtc0
crw-rw---- 1 root audio 253, 0 Jan 10 20:00 /dev/rtc0
# grep audio /etc/security/limits.conf
@audio - rtprio 99
@audio - memlock unlimited
My user is a member of the audio group.
This is a pure ALSA system, so there is no pulseaudio that could be
the culprit. pipewire is installed, but have not been running at any
time, although there might be something there?
As far as I've figured, when it last worked I was on a 6.4.x kernel,
I've been through a 6.5.x and have now had this problem on a few
different 6.6.x kernels.
From what I can gather, I've not changed anything that I can see. All
help welcome.
Regards,
Arve
10 p.m.
On Tue, 23 Jan 2024 at 21:43, Chris Caudle <chris(a)chriscaudle.org> wrote:
On Jan 23 2024, at 2:38 pm, Chris Caudle <chris(a)chriscaudle.org> wrote:
Can you show the output of `ulimit -a` to display the permissions currently active for
your logged in account?
The open files seems low, but I don't think that could impact this?
The scheduling priority maybe?
$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128156
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 128156
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Cheers,
Arve
24 Jan
24 Jan
10:33 a.m.
Hello Arve,
On 23-01-2024 22:00, Arve Barsnes wrote:
real-time priority (-r) 99
Maybe it's related to Real-Time group scheduling, see
https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt
You can disable it by setting the value of sched_rt_runtime_us to -1:
echo -n -1 | sudo tee /proc/sys/kernel/sched_rt_runtime_us
Haven't dealt with this myself so it's a long shot. But I did come
across reports where users got the ability of setting rtprio back after
disabling sched_rt_runtime_us.
Best,
Jeremy
6:14 p.m.
On Wed, 24 Jan 2024 at 16:55, Chris Caudle <chris(a)chriscaudle.org> wrote:
On Jan 24 2024, at 3:33 am, Jeremy Jongepier
<jeremy(a)autostatic.com> wrote:
Maybe it's related to Real-Time group scheduling, see
https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt
That certainly seems like a good possibility to investigate.
This note is on that document page you referenced:
Realtime group scheduling means you have to assign a portion of total CPU
bandwidth to the group before it will accept realtime tasks. Therefore you will
not be able to run realtime tasks as any user other than root until you have
done that, even if the user has the rights to run processes with realtime
priority!
That was it! Setting sched_rt_runtime_us to -1 allowed qjackctl to
start jack, and ardour seemed to start normally, thanks Jeremy!
Chris/Jeremy, reading the link, my previous values for the two
sched_rt_* settings in proc were the default values, but to make it
work I would have to "allocate realtime bandwidth" to the audio group
I think? Is it just as well to disable CONFIG_RT_GROUP_SCHED in my
kernel? Or is the change in /proc I did now permanent?
Thanks again!
Arve
25 Jan
25 Jan
1:38 p.m.
Hello Arve,
On 24-01-2024 18:14, Arve Barsnes wrote:
That was it! Setting sched_rt_runtime_us to -1 allowed
qjackctl to
start jack, and ardour seemed to start normally, thanks Jeremy!
Yes, good to hear it works again!
Chris/Jeremy, reading the link, my previous values for
the two
sched_rt_* settings in proc were the default values, but to make it
work I would have to "allocate realtime bandwidth" to the audio group
I think? Is it just as well to disable CONFIG_RT_GROUP_SCHED in my
kernel?
From what I understand this doesn't make any difference:
/proc/sys/kernel/sched_rt_runtime_us:
A global limit on how much time realtime scheduling may use. Even
without CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to
realtime processes. With CONFIG_RT_GROUP_SCHED it signifies the total
bandwidth available to all realtime groups.
Or is the change in /proc I did now permanent?
No it's not, you will have to set it through sysctl by adding the
following line to either an existing and fitting file or a new file in
/etc/sysctl/sysctl.d/:
kernel.sched_rt_runtime_us = -1
It will then get picked up during boot. To activate this setting on a
running system a `sudo sysctl --system` should do the trick.
Jeremy
4:33 p.m.
On Thu, 25 Jan 2024 at 13:38, Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
This is highly technical, but it could be read in a way such that
enabling this enables the whole group scheduling dynamic, and the
default is that all of it is allocated to root. If that makes sense,
disabling group scheduling would make the whole realtime bandwidth
available to "the system", and not limited to root, even if realtime
processes can still not use the whole system bandwidth.
I'm not quite able to wrap my head around the details here, so I'll go
for the sysctl solultion (at least for now).
Thank you so much Jeremy (and Chris)!
Arve
Is it just as
well to disable CONFIG_RT_GROUP_SCHED in my kernel?
From what I understand this doesn't make any difference:
/proc/sys/kernel/sched_rt_runtime_us:
A global limit on how much time realtime scheduling may use. Even
without CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to
realtime processes. With CONFIG_RT_GROUP_SCHED it signifies the total
bandwidth available to all realtime groups. 
23 Jan
23 Jan
11:59 p.m.
New subject: *** SPAM *** Unable to start jack in real-time mode
Le Tue, 23 Jan 2024 20:35:39 +0100,
Arve Barsnes <arve.barsnes(a)gmail.com> a écrit :
I'm "suddenly" (after a couple months of
disuse) unable to start jack
in real-time mode, making ardour unable to take advantage of it. I've
had more or less the same setup for more than 10 years, so I've really
forgotten if there is anything else than the below that I could
investigate.
Tue Jan 23 20:21:51 2024: ERROR: Cannot use real-time
scheduling
(RR/10) (1: Operation not permitted)
Tue Jan 23 20:21:51 2024: ERROR: AcquireSelfRealTime error
I recently needed jack real-time mode and got the same error in
addition to another one: "Cannot lock down 107341340 bye memory area".
Adding capabilities to jackd executable file with:
sudo setcap \
cap_sys_resource,cap_ipc_lock,cap_sys_nice=pie \
/usr/bin/jackd
fixed the issue.
Surprisingly, I don't find this trick in any tutorial on the net.
I'm not sure it works in your case, but it might be worth a try.
Yves
104
days inactive
106
days old
linux-audio-user@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Arve Barsnes -
Chris Caudle -
Jeremy Jongepier -
Yves Guillemot