24 Aug
2025
24 Aug
'25
4:15 p.m.
Hi
I running into issues with the jack_is_realtime(client) currently. The
issue is, when the user didn't have permission to run real-time tasks,
jackd starts with no real-time permission but jack_is_realtime(client)
reports true as soon the -R is in the jackd commandline. The same is
true for jack_client_real_time_priority(client). This call reports the
real-time priority given in the command line, but not the one in use.
So, when jackd starts without real-time priority, but -R is given on the
command-line, it reports the priority from jackdrc while it runs at
SCHED_OTHER without any priority.
Now, when I want to start my own threads I cant relay on the values
reported by jackd, which render the functions useless.
I need to run my own tests in order to check if real-time priority could
be set by the user or not.
regards
hermann
24 Aug
24 Aug
4:40 p.m.
New subject: [LAD] Re: jack_is_realtime(client) issues
On Sun, Aug 24, 2025 at 04:15:37PM +0200, Hermann Meyer wrote:
I need to run my own tests in order to check if
real-time priority could be
set by the user or not.
I use this:
int policy;
struct sched_param schedpar;
pthread_getschedparam (jack_client_thread_id (_jack_client), &policy, &schedpar);
Ciao,
--
FA
25 Aug
25 Aug
8:13 a.m.
New subject: [LAD] Re: jack_is_realtime(client) issues
On August 24, 2025 4:15:37 PM GMT+02:00, Hermann Meyer <brummer-(a)web.de> wrote:
Hi
I running into issues with the jack_is_realtime(client) currently. The issue is, when the
user didn't have permission to run real-time tasks, jackd starts with no real-time
permission but jack_is_realtime(client) reports true as soon the -R is in the jackd
commandline. The same is true for jack_client_real_time_priority(client). This call
reports the real-time priority given in the command line, but not the one in use. So, when
jackd starts without real-time priority, but -R is given on the command-line, it reports
the priority from jackdrc while it runs at SCHED_OTHER without any priority.
Now, when I want to start my own threads I cant relay on the values reported by jackd,
which render the functions useless.
I need to run my own tests in order to check if real-time priority could be set by the
user or not.
regards
hermann
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev(a)lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-leave(a)lists.linuxaudio.org
The documentation for this API call is a little unclear about what it really does:
<https://jackaudio.org/api/group__ClientFunctions.html#ga15719a4abdcc5fa8415167dd6ed6512c>
And one could consider the implementation to be conforming.
I would still consider this a bug though - but rather both in the documentation and the
implementation.
Also wasn't there a difference between jack1 and jack2 in how they handle the failure
to acquire rt scheduling? IIRC jack1 errors out while jack2 just prints a warning.
With jack1 the behaviour then would be precisely what one wants since -R and having this
call returning 1 actually implies having rt scheduling. With jack2 that's not the case
anymore.
Kind regardsv
FPS
9:33 a.m.
New subject: [LAD] Re: jack_is_realtime(client) issues
Am 25.08.25 um 08:13 schrieb Florian Paul Schmidt:
On August 24, 2025 4:15:37 PM GMT+02:00, Hermann
Meyer<brummer-(a)web.de> wrote:
As I want to know if jack run with realtime privileges before I activate
the client I cant use the solution from Fons. My solution for now is to
create a test thread and check if I could set it to SCHED_FIFO. If that
works I could trust the outcome from jack_is_realtime(client) and
jack_client_real_time_priority(client). If not, I assume that jack
didn't run with realtime privileges and init my threads into SCHED_OTHER.
regards
hermann
Hi
I running into issues with the jack_is_realtime(client) currently. The issue is, when the
user didn't have permission to run real-time tasks, jackd starts with no real-time
permission but jack_is_realtime(client) reports true as soon the -R is in the jackd
commandline. The same is true for jack_client_real_time_priority(client). This call
reports the real-time priority given in the command line, but not the one in use. So, when
jackd starts without real-time priority, but -R is given on the command-line, it reports
the priority from jackdrc while it runs at SCHED_OTHER without any priority.
Now, when I want to start my own threads I cant relay on the values reported by jackd,
which render the functions useless.
I need to run my own tests in order to check if real-time priority could be set by the
user or not.
regards
hermann
_______________________________________________
Linux-audio-dev mailing list --linux-audio-dev(a)lists.linuxaudio.org
To unsubscribe send an email tolinux-audio-dev-leave(a)lists.linuxaudio.org
The
documentation for this API call is a little unclear about what it really does:
<https://jackaudio.org/api/group__ClientFunctions.html#ga15719a4abdcc5fa8415167dd6ed6512c>
And one could consider the implementation to be conforming.
I would still consider this a bug though - but rather both in the documentation and the
implementation.
Also wasn't there a difference between jack1 and jack2 in how they handle the failure
to acquire rt scheduling? IIRC jack1 errors out while jack2 just prints a warning.
With jack1 the behaviour then would be precisely what one wants since -R and having this
call returning 1 actually implies having rt scheduling. With jack2 that's not the case
anymore.
Kind regardsv
FPS
______________________
12:55 p.m.
New subject: [LAD] Re: jack_is_realtime(client) issues
On 8/25/2025 9:33 AM, Hermann Meyer wrote:
As I want to know if jack run with realtime privileges
before I activate
the client I cant use the solution from Fons. My solution for now is to
create a test thread and check if I could set it to SCHED_FIFO. If that
works I could trust the outcome from jack_is_realtime(client) and
jack_client_real_time_priority(client). If not, I assume that jack
didn't run with realtime privileges and init my threads into SCHED_OTHER.
I guess this approach is sensible under the assumption that jack failing
to acquire rt scheduling implies your test thread failing to acquire rt
scheduling.
I would still file a bug with jack IMHO
Kind regards,
FPS
--
https://blog.dfdx.eu
164
days inactive
165
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
参加者 (3)
-
Florian Paul Schmidt -
Fons Adriaensen -
Hermann Meyer