25 May
2016
25 May
'16
2:20 p.m.
Luka Prin?i? / Nova deViator:
Renoise seems to be running some threads with FIFO
scheduler with a
priority that is _below_ that of JACK and firewire driver (correct
right?), but ALSO some threads using Round Robin scheduler with VERY
HIGH RT priority of 95. my question is if this is a possible cause for
glitches and XRUNS?
This thread could be a watchdog thread, in which case a priority of 95
should be unproblematic.
The glitches and XRUNS you see are probably due to other reasons
than thread priorities. Renoise is probably doing some time consuming things
in the jack thread, or is the victim of priority inversion, or waiting for
a non-realtime thread doing some work.
27 May
27 May
9:26 a.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
Kjetil Matheussen <k.s.matheussen(a)gmail.com>om>:
thanks,
this is interesting.
i'm slowly coming to conclusion that nothing
really helps regarding Renoise when it communicates with other
programs. as standalone there are no problems, no (serious) glitches.
but when sending MIDI to SuperCollider which converts that to OSC and
sends that to Processing it just stutters intolerably from time to
time. happened during live performance about three times two days
ago. :(. it's really a shame since I love it and will continue using it
for composition, but, live situation - composing audio-visuals - seems
like no go.
if anyone's curious, I have tried (this was actually primary setup)
Renoise on laptop, sending MIDI to SuperCollider sending OSC over the
network to video machine with Processing runnning. very similar
situation. glitches. few, but still too many.
in very near future I plan to do some stress tests with only
SuperCollider doing audio-intensive work and triggering Processing at
the same time. we'll see how that goes if I take Renoise out of
equation.
in the meantime, there's also a little thread on Renoise forums:
http://forum.renoise.com/index.php/topic/47767-linux-priority-too-high/
ha, also discovered there's a separate tuning list
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
best,
Luka
Luka Prin?i?
/ Nova deViator:
Renoise seems to be running some threads with
FIFO scheduler with a
priority that is _below_ that of JACK and firewire driver (correct
right?), but ALSO some threads using Round Robin scheduler with VERY
HIGH RT priority of 95. my question is if this is a possible cause
for glitches and XRUNS?
This thread could be a watchdog thread, in which case a priority of 95
should be unproblematic.
The glitches and XRUNS you see are probably due to other reasons
than thread priorities. Renoise is probably doing some time consuming
things in the jack thread, or is the victim of priority inversion, or
waiting for a non-realtime thread doing some work. 
10:11 a.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
On Fri, May 27, 2016 at 8:26 AM, Luka Prinčič / Nova deViator <
nova(a)deviator.si> wrote:
in very near future I plan to do some stress tests
with only
SuperCollider doing audio-intensive work and triggering Processing at
the same time. we'll see how that goes if I take Renoise out of
equation.
Good plan. Note that just a cpu-burn program will not stress the network,
disk or other parts - try a cpu burn while also downloading something large
and copying some files while running "sync" every few seconds :)
ha, also discovered there's a separate tuning
list
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
Most recent post - 2012. Although there is a huge amount of info available
about latency tuning and related topics, lots of it is outdated now
unfortunately.
-Harry
--
http://www.openavproductions.com
10:32 a.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
Hi,
On 27 May 2016 at 08:26, Luka Prinčič / Nova deViator <nova(a)deviator.si> wrote:
when sending MIDI to SuperCollider which converts that
to OSC and
sends that to Processing it just stutters intolerably from time to
time.
While it's probably not the cause of your issue, I'm interested why
you're sending the data destined for Processing through SuperCollider
to convert it into OSC rather than communicating with Processing
directly? Or is SuperCollider also transforming the data aimed at the
visual side?
Incidentally (and of course I'm biased :-) ) you should check out
Praxis LIVE for working with Processing in a live scenario -
www.praxislive.org / https://youtu.be/c1rI6_Lg3eQ
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Digital Prisoners - interactive spaces and projections -
www.digitalprisoners.co.uk
6:54 p.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
Neil C Smith <neilcsmith.net(a)googlemail.com>om>:
While it's probably not the cause of your issue,
I'm interested why
you're sending the data destined for Processing through SuperCollider
to convert it into OSC rather than communicating with Processing
directly? Or is SuperCollider also transforming the data aimed at the
visual side?
the main reason for that is/was that Renoise is unable to send any
decent OSC. there's a 'tool' in Renoise for that but it's missing to
send some OSC (skipping) - at least at the time it just wasn't working
correctly (didn't check the recent versions of Renoise for that -
there's been some changes in the Lua API i think.
another reason was that at first i was using two computers - one for
audio and the other for video. but that produced glitches too the
moment i was sending stuff via network
(Renoise midi -> SuperCollider OSC -> network -> Processing)
also, i'm interested in writing stuff in SuperCollider (including GUIs
used on a big touch screen).
i guess i need first to compile a decent proper RT kernel. will my
NVidia drivers work with that?
Incidentally (and of course I'm biased :-) ) you
should check out
Praxis LIVE for working with Processing in a live scenario -
www.praxislive.org / https://youtu.be/c1rI6_Lg3eQ
very interesting. checking it out!
l
--
Luka Prinčič / Nova deViator // + 386-40-66-77-98 / http://deviator.si /
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://wndv.bandcamp.com/album/recursion-ep
https://youtu.be/4D2cTyAmj0k
PATREON: http://patreon.com/novadeviator
7:04 p.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
On 27 May 2016 at 17:53, Luka Prinčič / Nova deViator <nova(a)deviator.si> wrote:
the main reason for that is/was that Renoise is unable
to send any
decent OSC.
I was thinking kind of the opposite - handling MIDI in Processing. Or
have I missed a reason you need to use OSC?
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Digital Prisoners - interactive spaces and projections -
www.digitalprisoners.co.uk
7:45 p.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
On Fri, 27 May 2016 18:53:46 +0200, Luka Prinčič / Nova deViator wrote:
i guess i need first to compile a decent proper RT
kernel. will my
NVidia drivers work with that?
Hi,
if you're using a vanilla kernel, with boot option threadirqs
proprietary drivers could be used. If you build a rt patched kernel,
then regarding https://aur.archlinux.org/packages/nvidia-rt/, there
nowadays seems to be no need to patch and pray anymore.
However, you should compare the free and the proprietary driver, since
they could affect the real-time quality, IOW one driver could be better
than the other. Regarding 3D abilities the nouveau not necessarily is
less good.
Regards,
Ralf
9:48 p.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
On Fri, May 27, 2016 12:45 pm, Ralf Mardorf wrote:
if you're using a vanilla kernel, with boot option
threadirqs
proprietary drivers could be used.
In the past the kernel needed to be compiled with the CONFIG_PREEMPT flag
for threadirqs to be available. I do not know if that is still true.
On Fedora at least the standard kernel does not use CONFIG_PREEMPT
(standard low latency) setting, it still uses CONFIG_PREEMPT_VOLUNTARY
which is less good for low latency use.
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
Look at the kernel config in use, in order from worst to best the PREEMPT
options are:
CONFIG_PREEMPT_NONE <- don't use this one
CONFIG_PREEMPT_VOLUNTARY <-- not good for low latency
CONFIG_PREEMPT <- could be good for most use, test for
yourself
CONFIG_PREEMPT-RT <- lowest latency, requires out of tree RT
patches
--
Chris Caudle
29 May
29 May
10:27 a.m.
New subject: realtime priority - FIFO vs Round Robin and scheduling
On Fri, 27 May 2016 18:53:46 +0200
Luka Prinčič / Nova deViator <nova(a)deviator.si> wrote:
i guess i need first to compile a decent proper RT
kernel. will my
NVidia drivers work with that?
Yes, unless you are still using something older like 340.xx. Older
nvidia drivers need a switch to compile for a -rt patched kernel, see
the use of IGNORE_PREEMPT_RT_PRESENCE=1 at
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia-340xx-rt
Newer nvidia drivers will build fine with a -rt patched kernel.
You will however have to patch the kernel itself, as otherwise X hangs
very quickly..:S There are 2 versions. Kernels before 4.4.4-rt11,
need this patch:
https://aur.archlinux.org/cgit/aur.git/tree/fix-race-in-PRT-wait-for-comple…
Later kernels this one:
https://aur.archlinux.org/cgit/aur.git/tree/fix-race-in-PRT-wait-for-comple…
Note that the nvidia driver is less than desirable with rt, as it
causes higher kernel scheduling latencies compared to for instance the
intel driver. I guess it's probably usable for audio work, but certain
actions will cause a kernel latency spike big enough to cause xruns on
lower latencies. These include starting video playback, starting a
game, etc. This may or may not cause a problem in your particular
situation. IIRC nouveau worked much better for this purpose, but was a
long time ago that i last tried...
--
Joakim
2897
days inactive
2901
days old
linux-audio-user@lists.linuxaudio.org
8 comments
7 participants
participants (7)
-
Chris Caudle -
Harry van Haaren -
Joakim Hernberg -
Kjetil Matheussen -
Luka Prinčič / Nova deViator -
Neil C Smith -
Ralf Mardorf