Hey all
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods). Glitches happen more frequently when UDP streaming is on, but don't completely disappear when I stop UDP transmission. So, relatively to macOS, Pd seems to be more prone to glitches on Linux.
Just to be sure that my Linux machine is up to task I tuned it with the help of [1]. I get very stable performance with softwares like Ardour, even under load. It's only Pd that creates glitches. I also observed that Pd experiences drop outs while jack reports not glitches. I believe to have observed that ardour only glitches when jack does. So, it seems Pd is less "tightly coupled" to jack, does that sound right?
Is there anything I can do to tune Pd for stable low latency (on Linux)?
BTW: What happened to those messages when running with -rt:
"priority 6 scheduling enabled. priority 8 scheduling enabled."
Roman
in my years using pd on linux i have never gotten it to work with low latency and jack. same as you i always got glitches and dropouts.
with alsa it is fine…
On 29 Jan 2018, at 10:25, Roman Haefeli reduzent@gmail.com wrote:
Hey all
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods). Glitches happen more frequently when UDP streaming is on, but don't completely disappear when I stop UDP transmission. So, relatively to macOS, Pd seems to be more prone to glitches on Linux.
Just to be sure that my Linux machine is up to task I tuned it with the help of [1]. I get very stable performance with softwares like Ardour, even under load. It's only Pd that creates glitches. I also observed that Pd experiences drop outs while jack reports not glitches. I believe to have observed that ardour only glitches when jack does. So, it seems Pd is less "tightly coupled" to jack, does that sound right?
Is there anything I can do to tune Pd for stable low latency (on Linux)?
BTW: What happened to those messages when running with -rt:
"priority 6 scheduling enabled. priority 8 scheduling enabled."
Roman
[1] https://github.com/raboof/realtimeconfigquickscan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods).
Update: My personal, somewhat outdated laptop from 2007 has absolutely stable performance with same patch, same Pd version, same OS, same kernel. To be clear: It's only Pd that performs well on one computer and not so well on others. I get glitch-free audio with Ardour on all tested computers. So I wonder what circumstances affect specifically Pd. It's a pity the most powerful computer I have access to is in its current state not suitable for Pd projects :-(
Roman
On 30/01/2018 11:07, Roman Haefeli wrote:
On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods).
Update: My personal, somewhat outdated laptop from 2007 has absolutely stable performance with same patch, same Pd version, same OS, same kernel. To be clear: It's only Pd that performs well on one computer and not so well on others. I get glitch-free audio with Ardour on all tested computers. So I wonder what circumstances affect specifically Pd. It's a pity the most powerful computer I have access to is in its current state not suitable for Pd projects :-(
One thing to try from totally non-scientific personal experience would be to look into CPU scaling stuff when using Pd. The fact that an old machine works well possibly hints that this might be the culprit, so worth trying. I experimented with this when pushing my Granita granulator with realtime input being fed to the buffer and trying to eliminate as much as possilbe "smart" CPU stuff improved things quite a lot... On my previous laptop I could set various governors on my current one there is only powersave and performance, the latter should work, but also trying to set a fixed frequency... You have to experiment a bit.
Kernel documentation: https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html
Arch-specific but possibly some interesting general information: https://wiki.archlinux.org/index.php/CPU_frequency_scaling
Also for Debian (and possibly Ubuntu): https://wiki.debian.org/HowTo/CpuFrequencyScaling
Red Hat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
My two cents. Lorenzo
On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:
On 30/01/2018 11:07, Roman Haefeli wrote:
On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods).
Update: My personal, somewhat outdated laptop from 2007 has absolutely stable performance with same patch, same Pd version, same OS, same kernel. To be clear: It's only Pd that performs well on one computer and not so well on others. I get glitch-free audio with Ardour on all tested computers. So I wonder what circumstances affect specifically Pd. It's a pity the most powerful computer I have access to is in its current state not suitable for Pd projects :-(
One thing to try from totally non-scientific personal experience would be to look into CPU scaling stuff when using Pd. The fact that an old machine works well possibly hints that this might be the culprit, so worth trying. I experimented with this when pushing my Granita granulator with realtime input being fed to the buffer and trying to eliminate as much as possilbe "smart" CPU stuff improved things quite a lot... On my previous laptop I could set various governors on my current one there is only powersave and performance, the latter should work, but also trying to set a fixed frequency... You have to experiment a bit.
Thanks for mentioning that. Setting the governor to 'performance' for all cores is part of my standard setup when going into 'performance' mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I need the scaling governor to set to 'performance'. To my non-scientific eye it looks like Pd in realtime mode has a higher priority than the service controlling CPU frequency, so that switching to a new frequency would happen only after Pd's need for it is over.
The issue I'm having here is not related to CPU frequency scaling (at least not exclusively). Even when all cores run under 'performance' and at maximum clock speed, I get crackles with the new laptop (CPU: Intel Core i5-7300U). Yet, the only reliable way known to me so far to get running Pd crackle-free is to run four instances of 'yes > /dev/null &'. This seems to keep whatever resource Pd needs to access quickly awake and available. While those four instances of 'yes' are running in the background, it doesn't matter what governor I set since they keep the cores at their maximum frequency anyway.
Roman
On Wed, Feb 7, 2018 at 9:26 AM, Roman Haefeli reduzent@gmail.com wrote:
On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:
On 30/01/2018 11:07, Roman Haefeli wrote:
On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
I'm working on a patch that transmits audio through UDP. The patch runs totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as back-end. On the Linux machines I tested (all Ubuntu 16.04) with the same version of Pd I get a lot of glitches, although I'm using very similar Jack settings (128 frames/period, 3 periods).
Update: My personal, somewhat outdated laptop from 2007 has absolutely stable performance with same patch, same Pd version, same OS, same kernel. To be clear: It's only Pd that performs well on one computer and not so well on others. I get glitch-free audio with Ardour on all tested computers. So I wonder what circumstances affect specifically Pd. It's a pity the most powerful computer I have access to is in its current state not suitable for Pd projects :-(
One thing to try from totally non-scientific personal experience would be to look into CPU scaling stuff when using Pd. The fact that an old machine works well possibly hints that this might be the culprit, so worth trying. I experimented with this when pushing my Granita granulator with realtime input being fed to the buffer and trying to eliminate as much as possilbe "smart" CPU stuff improved things quite a lot... On my previous laptop I could set various governors on my current one there is only powersave and performance, the latter should work, but also trying to set a fixed frequency... You have to experiment a bit.
Thanks for mentioning that. Setting the governor to 'performance' for all cores is part of my standard setup when going into 'performance' mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I need the scaling governor to set to 'performance'. To my non-scientific eye it looks like Pd in realtime mode has a higher priority than the service controlling CPU frequency, so that switching to a new frequency would happen only after Pd's need for it is over.
The issue I'm having here is not related to CPU frequency scaling (at least not exclusively). Even when all cores run under 'performance' and at maximum clock speed, I get crackles with the new laptop (CPU: Intel Core i5-7300U). Yet, the only reliable way known to me so far to get running Pd crackle-free is to run four instances of 'yes > /dev/null &'. This seems to keep whatever resource Pd needs to access quickly awake and available. While those four instances of 'yes' are running in the background, it doesn't matter what governor I set since they keep
the cores at their maximum frequency anyway.
Maybe there's a way to force all the Pd-related processes to run on the same core, as it could be that the transfer of memory from one to the other causes glitches, so if jackd is on a different core than Pd there will be latency as they transfer access to the buffer from one to the other. Just guessing...
Martin
On Mit, 2018-02-07 at 09:46 -0500, Martin Peach wrote:
Maybe there's a way to force all the Pd-related processes to run on the same core, as it could be that the transfer of memory from one to the other causes glitches, so if jackd is on a different core than Pd there will be latency as they transfer access to the buffer from one to the other. Just guessing...
I tried: * turning hyperthreading off * putting pd and jackd on the same core * putting pd and jackd on different cores
but those configurations don't seem to affect the current situation at all.
Please someone correct me here, but I think it does not matter if pd and jackd run on the same core, since they seem to communicate through /dev/shm, so there is no gain to be made by being closer together. I'd say it makes even sense to separate them so that overall more CPU power is available for both.
Also, the fact the running x instances of 'yes' in the background helps indicates that the problem is not the communication between pd and jackd.
Roman
On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli reduzent@gmail.com wrote:
On Mit, 2018-02-07 at 09:46 -0500, Martin Peach wrote:
Maybe there's a way to force all the Pd-related processes to run on the same core, as it could be that the transfer of memory from one to the other causes glitches, so if jackd is on a different core than Pd there will be latency as they transfer access to the buffer from one to the other. Just guessing...
I tried:
- turning hyperthreading off
- putting pd and jackd on the same core
- putting pd and jackd on different cores
but those configurations don't seem to affect the current situation at all.
There's also wish, the tcl/tk component.
Please someone correct me here, but I think it does not matter if pd and jackd run on the same core, since they seem to communicate through /dev/shm, so there is no gain to be made by being closer together. I'd say it makes even sense to separate them so that overall more CPU power is available for both.
Also, the fact the running x instances of 'yes' in the background helps indicates that the problem is not the communication between pd and jackd.
Yes it sounds like the things go to sleep when nothing happens for a few
nanoseconds or something. It should be documented somewhere on kernel.org.
Martin
On Mit, 2018-02-07 at 10:41 -0500, Martin Peach wrote:
On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli reduzent@gmail.com
I tried: * turning hyperthreading off * putting pd and jackd on the same core * putting pd and jackd on different cores
but those configurations don't seem to affect the current situation at all.
There's also wish, the tcl/tk component.
To eliminate as many factors as possible, I run [adc~]-[dac~] in:
pd -noprefs -nogui -rt -jack -channels 2 -open shortcircuit.pd
But even when I run with GUI, wish and pd communicate through a network socket. It shouldn't matter if they share a core, or should it?
Yes it sounds like the things go to sleep when nothing happens for a few nanoseconds or something.
Exactly, and I haven't the slightest clue what it is.
It should be documented somewhere on kernel.org.
I don't feel competent enough for that.
Roman