26 Jan
2023
26 Jan
'23
11:04 a.m.
Hi, I just read about a possibly outdated advice to increase the nice
value of Xorg (currently 19 on my Debian stable system) to avoid audio
dropouts when switching desktops etc. Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
Thanks in advance! Peter
26 Jan
26 Jan
11:47 a.m.
Am 26.01.23 um 10:03 schrieb Peter P.:
Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
+1
Sounds like a good idea.
Just for trying this out: Use top/htop and change the niceness of X.
But besides making this persistent: What about wayland sessions?
Found a line (to be precise: 3 lines) named
/usr/libexec/gdm-wayland-session /usr/bin/gnome-session
which could be responsible…
Am I right?
Greets!
Mitsch
12:04 p.m.
On Thu, Jan 26, 2023 at 10:47:14AM +0100, Michael Jarosch wrote:
Am 26.01.23 um 10:03 schrieb Peter P.:
I'm not so sure. If the audio processing is done in real-time
threads and these threads do not interact with X in any way
that could block them (as things should be), then this won't
help.
The only way X could interrupt audio in that case is by having
real-time threads as well, and the nice value won't affect
those.
Ciao,
--
FA
Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
Sounds like a good idea.
12:09 p.m.
* Fons Adriaensen <fons(a)linuxaudio.org> [2023-01-26 11:04]:
On Thu, Jan 26, 2023 at 10:47:14AM +0100, Michael
Jarosch wrote:
Thanks Fons,
I my case I am trying to optimize Pd, which has a GUI that is somehow
interlocked with its audio thread.
best, P
Am 26.01.23 um 10:03 schrieb Peter P.:
I'm not so sure. If the audio processing is done in real-time
threads and these threads do not interact with X in any way
that could block them (as things should be), then this won't
help.
The only way X could interrupt audio in that case is by having
real-time threads as well, and the nice value won't affect
those. Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
Sounds like a good idea. 
7:15 p.m.
Maybe a ridiculous solution: you could run pd headless and make an
interface with it using osc or midi so you can use another program as
your gui (if you need one). Let us know how the niceness thing works
though, I'm curious to hear if there is a difference.
On 1/26/23 05:09, Peter P. wrote:
* Fons Adriaensen <fons(a)linuxaudio.org>
[2023-01-26 11:04]:
On Thu, Jan 26, 2023 at 10:47:14AM +0100, Michael
Jarosch wrote:
Thanks Fons,
I my case I am trying to optimize Pd, which has a GUI that is somehow
interlocked with its audio thread.
best, P
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user Am 26.01.23 um 10:03 schrieb Peter P.:
I'm not so sure. If the audio processing is done in
real-time
threads and these threads do not interact with X in any way
that could block them (as things should be), then this won't
help.
The only way X could interrupt audio in that case is by having
real-time threads as well, and the nice value won't affect
those. Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
Sounds
like a good idea. 
8:01 p.m.
On 26/01/2023 11:09, Peter P. wrote:
* Fons Adriaensen <fons(a)linuxaudio.org>
[2023-01-26 11:04]:
Not specific to the subjet line but...
Is/are your patch(es) 'gui-heavy', which in Pd would be e.g. lots of
bangs or changing number-boxes? That in my experience has been cause of
audio drop-outs. Also make sure to run pd with the -rt flag and if you
are on a laptop make sure to disable WiFi.
Knowing more about the patch(es) is always very useful when trying to
debug Pd IMHO :-)
Lorenzo
On Thu, Jan 26, 2023 at 10:47:14AM +0100, Michael
Jarosch wrote:
Thanks Fons,
I my case I am trying to optimize Pd, which has a GUI that is somehow
interlocked with its audio thread. Am 26.01.23 um 10:03 schrieb Peter P.:
I'm not so sure. If the audio processing is done in real-time
threads and these threads do not interact with X in any way
that could block them (as things should be), then this won't
help.
The only way X could interrupt audio in that case is by having
real-time threads as well, and the nice value won't affect
those. Can anyone comment on the
usefulness or experiences with changing it (where would one change it?)?
Sounds like a good idea.
449
days inactive
449
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Brandon Hale -
Fons Adriaensen -
Lorenzo Sutton -
Michael Jarosch -
Peter P.