Hi again!
I am having trouble getting the latency of PD down. I asked the linux-audio-users list about kernel and jack related optimizations, so now I ask you:
How do I tune PD to run as fast as possible?
For example I can get jackd to run with a 10ms latency without XRUNS, but when I open pd and move the window around or change windows I get pops. I know this is largely because of gnome (and I would like some hints there as well), but what can I do about PD?
Thanks! -thewade
Hi Wade,
thewade wrote:
How do I tune PD to run as fast as possible?
I'm sure you have a lot of these covered already!
- Run as root (or with LSM).
- Run with the -rt flag.
- Ditch Gnome and use something super-lightweight like fluxbox.
- Make sure there is no IRQ conflicts between your graphics card, sound
card and peripherals: --> http://tinyurl.com/7vhmc
- Using a shared-memory graphics card, such as the Intel chipset Frank
Barknecht discussed with Ed Kelly this week, is reported by RME to cause dropouts: --> http://tinyurl.com/dcdvk
- Also look into your hard drive access times if any disk activity needs
to happen during performance: --> http://tinyurl.com/cedtl
- Realtime, low latency kernel patches (does not apply to PPC achitecture!)
- Check out Linux Security Mode patches to run RT as non-root.
- Don't use frequently-updated graphics in your patches (i.e. VU meters
or number boxes connected to a fast stream of numbers, etc etc).
- Run one instance of pd -noaudio for your GUI, and use OSC to
communicate with another instance of pd -nogui for your DSP. The poor man's multithreading!
- Only start PD with as many ALSA/JACK channels as you need.
- Consider using -nodac/-noadc if they are not needed.
On Friday 18 November 2005 11:30, derek holzer wrote:
- Run one instance of pd -noaudio for your GUI, and use OSC to
communicate with another instance of pd -nogui for your DSP. The poor man's multithreading!
That will work best if you set the priority of the DSP-pd higher than the GUI-pd. For instance use the -rt flag only for pd -nogui. And of course a dual-cpu or dual-core system will help as well.
G
use pd devel 0.39 with -cb_scheduler it fixed my glitches
pat
----- Original Message ----- From: "vanDongen/Gilcher" gml@xs4all.nl To: pd-list@iem.at Sent: Friday, November 18, 2005 8:21 AM Subject: Re: [PD] PD and latency on kernel 2.6.14.2-lsm
On Friday 18 November 2005 11:30, derek holzer wrote:
- Run one instance of pd -noaudio for your GUI, and use OSC to
communicate with another instance of pd -nogui for your DSP. The poor man's multithreading!
That will work best if you set the priority of the DSP-pd higher than the GUI-pd. For instance use the -rt flag only for pd -nogui. And of course a dual-cpu or dual-core system will help as well.
G
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, derek holzer hat gesagt: // derek holzer wrote:
- Using a shared-memory graphics card, such as the Intel chipset Frank
Barknecht discussed with Ed Kelly this week, is reported by RME to cause dropouts: --> http://tinyurl.com/dcdvk
Note that Ed and I have the newer series of Intel GFX chip, which have a reworked architecture that should be less susceptible to this problem. It would be cool, if RME could update their page with some tests of the new chipsets. However some issues also have to do with the driver, which at least theoretically are fixable on Intel because the drivers as Open Source, however for NVidia you can only pray.
I don't have any unusual dropouts using the Intel chip on my laptop compared to the same patches on my main machine, which has a seperate gfx card.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
derek holzer wrote:
Hi Wade,
thewade wrote:
How do I tune PD to run as fast as possible?
I'm sure you have a lot of these covered already!
- Run as root (or with LSM).
- Run with the -rt flag.
- Ditch Gnome and use something super-lightweight like fluxbox.
- Make sure there is no IRQ conflicts between your graphics card,
sound card and peripherals: --> http://tinyurl.com/7vhmc
- Using a shared-memory graphics card, such as the Intel chipset Frank
Barknecht discussed with Ed Kelly this week, is reported by RME to cause dropouts: --> http://tinyurl.com/dcdvk
- Also look into your hard drive access times if any disk activity
needs to happen during performance: --> http://tinyurl.com/cedtl
- Realtime, low latency kernel patches (does not apply to PPC
achitecture!)
- Check out Linux Security Mode patches to run RT as non-root.
- Don't use frequently-updated graphics in your patches (i.e. VU
meters or number boxes connected to a fast stream of numbers, etc etc).
- Run one instance of pd -noaudio for your GUI, and use OSC to
communicate with another instance of pd -nogui for your DSP. The poor man's multithreading!
- Only start PD with as many ALSA/JACK channels as you need.
- Consider using -nodac/-noadc if they are not needed.
That kicks arse! I am using fluxbox now. I installed it last night (building tools like that is good busywork to distract from the hangover). It just died on me when I switched workspaces though... Someone should post this on some wiki somewhere! I am going to look into the irq issue as someone on the LAU list mentioned this as well. A couple of questions though: Does it help to run PD using nice? e.g. 'nice -5 pd' and jack with a priority of 70 or so? if I use -jack in my pdrc then -rt does nothing, right? I thought -rt wsa for alsa opperation. Thanks again for this list! I did cover many of thoes points, but I forgot a lot of them as well! -thewade
Hi,
on my boxes it helped to set the nice value of the xserver from -10 to 0 (on debian -10 seems to be the default). You can set it in /etc/X11/Xwrapper.config.
see also: http://plessas.mur.at/audio_computer.html
apropos jack: i always thought that pd's -rt flag and jackd's -R are two different things...?
peter
thewade wrote:
derek holzer wrote:
Hi Wade,
thewade wrote:
How do I tune PD to run as fast as possible?
I'm sure you have a lot of these covered already!
- Run as root (or with LSM).
- Run with the -rt flag.
- Ditch Gnome and use something super-lightweight like fluxbox.
- Make sure there is no IRQ conflicts between your graphics card,
sound card and peripherals: --> http://tinyurl.com/7vhmc
- Using a shared-memory graphics card, such as the Intel chipset Frank
Barknecht discussed with Ed Kelly this week, is reported by RME to cause dropouts: --> http://tinyurl.com/dcdvk
- Also look into your hard drive access times if any disk activity
needs to happen during performance: --> http://tinyurl.com/cedtl
- Realtime, low latency kernel patches (does not apply to PPC
achitecture!)
- Check out Linux Security Mode patches to run RT as non-root.
- Don't use frequently-updated graphics in your patches (i.e. VU
meters or number boxes connected to a fast stream of numbers, etc etc).
- Run one instance of pd -noaudio for your GUI, and use OSC to
communicate with another instance of pd -nogui for your DSP. The poor man's multithreading!
- Only start PD with as many ALSA/JACK channels as you need.
- Consider using -nodac/-noadc if they are not needed.
That kicks arse! I am using fluxbox now. I installed it last night (building tools like that is good busywork to distract from the hangover). It just died on me when I switched workspaces though... Someone should post this on some wiki somewhere! I am going to look into the irq issue as someone on the LAU list mentioned this as well. A couple of questions though: Does it help to run PD using nice? e.g. 'nice -5 pd' and jack with a priority of 70 or so? if I use -jack in my pdrc then -rt does nothing, right? I thought -rt wsa for alsa opperation. Thanks again for this list! I did cover many of thoes points, but I forgot a lot of them as well! -thewade
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Does it help to run PD using nice? e.g. 'nice -5 pd' and jack with a priority of 70 or so?
i doubt that ... pd is not a proper jack client, just renicing doesn't really help. the best latency i could achieve with the modified scheduler in pd, that tries to make pd a proper jack client.
if I use -jack in my pdrc then -rt does nothing, right? I thought -rt wsa for alsa opperation.
of you use pd with -rt, it will try to give pd realtime capabilities ... but this doesn't really help, if jack doesn't have realtime capabilities.
if you need lowest latencies, i'd recommend, you check out devel, since it reduces the latency by one io block size ...
but there are some design decisions in pd (it's better in devel, but still not optimal), that will _never_ allow pd to become a very low latency system...
cheers ... tim
Hi everyone.
That's an interesting thread, there are questions here I never dared to ask (-:
I'm surprised though to hear that Pd could not become such a good realtime application.
For my personal education Tim, what are the "design decisions" that will never allow Pd to become a very good latency system?
Thanks.
Jé
Tim Blechmann a écrit :
Does it help to run PD using nice? e.g. 'nice -5 pd' and jack with a priority of 70 or so?
i doubt that ... pd is not a proper jack client, just renicing doesn't really help. the best latency i could achieve with the modified scheduler in pd, that tries to make pd a proper jack client.
if I use -jack in my pdrc then -rt does nothing, right? I thought -rt wsa for alsa opperation.
of you use pd with -rt, it will try to give pd realtime capabilities ... but this doesn't really help, if jack doesn't have realtime capabilities.
if you need lowest latencies, i'd recommend, you check out devel, since it reduces the latency by one io block size ...
but there are some design decisions in pd (it's better in devel, but still not optimal), that will _never_ allow pd to become a very low latency system...
cheers ... tim
Jerome Tuncer wrote:
Hi everyone.
That's an interesting thread, there are questions here I never dared to ask (-:
I'm surprised though to hear that Pd could not become such a good realtime application.
from Word-Net: real-time adj : of or relating to computer systems that update information at the same rate they receive information
please note, that the word "latency" is nowhere mentioned. it has nothing to do with "realtime". (you can have a hard realtime system that has a delay of 1 week). so pd is by design a realtime system.
as for low latencies, the best i ever managed to get was measured(!) 4.5ms @ 44.1kHz, with plain OSS drivers (and lately with ALSA). this is pretty low for ordinary use. if you are doing music you should be totally fine with that. i guess only people doing technical dsp stuff (like echo cancellation) need to get lower latencies.
again: if you just want to record your trumpet and process it in real-time, i dare say that you do not need such low latencies. if somebody told you something else, they probably wanted to sell you something.
otoh, i am always seekings minimal latency too.
mfg.a.sdr IOhannes
hello iohannes and all,
Am Samstag 19 November 2005 00:13 schrieb IOhannes m zmoelnig: [...snip...]
please note, that the word "latency" is nowhere mentioned. it has nothing to do with "realtime". (you can have a hard realtime system that has a delay of 1 week). so pd is by design a realtime system.
ouch! that comment about hard realtime is plain wrong. hard realtime is used in systems where you need minimal delay, like engine controls, medical systems, etc.
imagine your life support systems would use hard realtime that can delay up to a week .....
the most important aspect of hard realtime systems (like rtlinux) is that they have the lowest latency possible!
also, see here: http://en.wikipedia.org/wiki/Real-time_computing
greets,
chris
Christian Klippel wrote:
hello iohannes and all,
Am Samstag 19 November 2005 00:13 schrieb IOhannes m zmoelnig: [...snip...]
please note, that the word "latency" is nowhere mentioned. it has nothing to do with "realtime". (you can have a hard realtime system that has a delay of 1 week). so pd is by design a realtime system.
ouch! that comment about hard realtime is plain wrong. hard realtime is used in systems where you need minimal delay, like engine controls, medical systems, etc.
i guess i was unclear (at least i was cryptic) "real-time" does say _nothing_ about the "amount of latency". however, the important thing is, that "realtime" guarantees processing within a "given latency" (however large that may be).
imagine your life support systems would use hard realtime that can delay up to a week .....
the most important aspect of hard realtime systems (like rtlinux) is that they have the lowest latency possible!
no, the most important thing is, that they have a maximum latency aka "deadline" that must not be exceeded.
also, see here: http://en.wikipedia.org/wiki/Real-time_computing
quoting this artile:
"It is important to note that hard versus soft real-time does not necessarily relate to the length of time available. A machine may overheat if a processor does not turn on cooling within 15 minutes (hard real-time). On the other hand, a network interface card may lose buffered data if it is not read within a fraction of a second, but the data can be resent over the network if needed, without affecting a critical operation, perhaps without a delay noticeable to the user."
but then i am no real time specialist.
mfg.adr IOhannes
Am Samstag 19 November 2005 09:09 schrieb IOhannes m zmölnig: [...snip...]
no, the most important thing is, that they have a maximum latency aka "deadline" that must not be exceeded.
also, see here: http://en.wikipedia.org/wiki/Real-time_computing
quoting this artile:
"It is important to note that hard versus soft real-time does not necessarily relate to the length of time available. A machine may overheat if a processor does not turn on cooling within 15 minutes (hard real-time). On the other hand, a network interface card may lose buffered data if it is not read within a fraction of a second, but the data can be resent over the network if needed, without affecting a critical operation, perhaps without a delay noticeable to the user."
ah, ok. then i was wrong. my understanding of realtime vs. hard realtime was always that realtime is like: to process an hour of audio, it needs an hour. but its uncertain when it is done. whereas under hard realtime i understood that things get processed as fast as possible within a guaranteed time. i was not thinking about when the result of that is sent, that can be done later. but the processing/capture (aquisition) of the data is "immediate". and latency for me means the time difference between the incomming event and the resulting outgoing event. so yes, a hard realtime thing can have a long latency....
but we never stop to learn, me included ;)
but then i am no real time specialist.
me neither ... ;)
mfg.adr IOhannes
greetings,
chris
Hallo, Christian Klippel hat gesagt: // Christian Klippel wrote:
hello iohannes and all,
Am Samstag 19 November 2005 00:13 schrieb IOhannes m zmoelnig: [...snip...]
please note, that the word "latency" is nowhere mentioned. it has nothing to do with "realtime". (you can have a hard realtime system that has a delay of 1 week). so pd is by design a realtime system.
ouch! that comment about hard realtime is plain wrong. hard realtime is used in systems where you need minimal delay, like engine controls, medical systems, etc.
imagine your life support systems would use hard realtime that can delay up to a week .....
the most important aspect of hard realtime systems (like rtlinux) is that they have the lowest latency possible!
also, see here: http://en.wikipedia.org/wiki/Real-time_computing
There I read something different, though:
A distinction can be made between those systems which will suffer a critical failure if time constraints are violated (hard or immediate real-time), and those which will not (soft real-time).
Note that this doesn't mention the size of the latency at all, it just speaks about violations of "time constraints", which themselves could be nanoseconds or years. Later on the same page:
It is important to note that hard versus soft real-time does not necessarily relate to the length of time available.
Q.e.d. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
For my personal education Tim, what are the "design decisions" that will never allow Pd to become a very good latency system?
pd is written as a single threaded application, if you read the pd code, you can see this everywhere ... the main pd thread does everything ... audio io, dsp computation, soundfile loading, object generation, gui communication, midi io, messaging ... basically everything.
but this is the contrary, how the audio hardware of all modern audio apis (jack, asio, coreaudio, portaudio, possibly alsa) works. the sound card sends an interrupt to the os, the driver calls a function in the program that should send/receive the audio data...
my approach for devel was to use this callback to drive the dsp computation, but to keep the system in sync, i have to lock the global pd mutex. so basically all functions that are run, while the global pd mutex is locked, should be executed, without locking the system for a too long time ...
cheers ... tim
On Sat, 19 Nov 2005, Tim Blechmann wrote:
but this is the contrary, how the audio hardware of all modern audio apis (jack, asio, coreaudio, portaudio, possibly alsa) works. the sound card sends an interrupt to the os, the driver calls a function in the program that should send/receive the audio data...
In an modern OS the driver doesn't call a user function.
There is no difference between callback based and blocking I/O in terms of latency, its only about scheduling.
On linux, the audio driver (in kernel space) only offers a blocking API. What JACK does is, it converts the blocking into a callback.
The way this is done is that the JACK library code in the application waits (blocks !!) until it gets a "go" from JACK directly (or the application that runs before in the JACK chain). Then the jack library calls a callback within the application. There is no (technical) reason why the application can't wait on the lock by itself, and if it gets a "go" does the calculations. One thing that has to be assured in this scenario is that the calculations are done fast enough (no blocking I/O, memory allocation, etc stuff) and that after the calculation control is handed over to the right process (the next one in the jack calculation chain).
Similar scenarios for portaudio, coreaudio, ASIO. Callback API doesn't mean lower latency, it is just easier and less errorprone than having to do the blocking explicitly.
Guenter
my approach for devel was to use this callback to drive the dsp computation, but to keep the system in sync, i have to lock the global pd mutex. so basically all functions that are run, while the global pd mutex is locked, should be executed, without locking the system for a too long time ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
thewade wrote:
That kicks arse! Someone should post this on some wiki somewhere!
Done.
http://puredata.info/community/pdwiki/Optimize
Have a blast. d.
"Use PD devel 0.39 with -cb_scheduler" What does this mean? Is -cb_scheduler a flag you pass at build time? I am using the cvs version of PD: pd -version Pd version 0.39-1 compiled 17:32:17 Oct 23 2005
Also I dont have an /etc/X11/Xwrapper.config file. (FC4) What should I do? Probably just use nice --5 huh? (Thanks Mathieu, BTW)
Thanks for posting that! -thewade
derek holzer wrote:
thewade wrote:
That kicks arse! Someone should post this on some wiki somewhere!
Done.
http://puredata.info/community/pdwiki/Optimize
Have a blast. d.
On Fri, 18 Nov 2005, thewade wrote:
A couple of questions though: Does it help to run PD using nice? e.g. 'nice -5 pd' and jack with a priority of 70 or so?
Note that "nice -5" means +5 while "nice --5" means -5
Also note that high values of priority mean low priority. (it's backwards)
And also note that negative values of priority require root.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
Christian Klippel -
derek holzer -
Frank Barknecht -
günter geiger -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jerome Tuncer -
Mathieu Bouchard -
patrick -
Peter Plessas -
thewade -
Tim Blechmann -
vanDongen/Gilcher