Is it running with the *same* OS and settings? It might be a scheduling issue with the kernel, realtime settings, crappy networking driver, etc.
On Jan 30, 2018, at 12:00 PM, pd-list-request@lists.iem.at wrote:
From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] glitches when streaming UDP Message-ID: <1517306864.2068.8.camel@gmail.com mailto:1517306864.2068.8.camel@gmail.com> Content-Type: text/plain; charset="utf-8"
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
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Die, 2018-01-30 at 16:38 +0100, Dan Wilcox wrote:
Is it running with the *same* OS and settings?
As far as I can tell: yes. Same OS (Ubuntu 16.04), same Kernel (4.13.0- 32-lowlatency), both tuned so that "realtimeconfigquickscan" doesn't complain anymore. This includes configuring /etc/security/limits.conf, adding user to audio group, making high-precision timer /dev/hpet und realtime clock /dev/rtc readable by members of audio group, etc. I get stable performance with Ardour with the same qjackctl settings, with built-in soundcard, but also with external USB sound interface on BOTH machines.
It might be a scheduling issue with the kernel, realtime settings, crappy networking driver, etc.
I thought about that, too. But why does it affect only Pd? On the "troubled" machine - where everything else runs supersmooth - this setup suffers a couple of glitches per second (jack routing):
mpv -> Pd running [adc~]-[dac~] -> system output
The probable causes you mentioned would affect other audio softwares, too, wouldn't they?
The Pd version doesn't seem to make a difference...
Anyway, thanks for your thoughts.
Roman
On Jan 30, 2018, at 12:00 PM, pd-list-request@lists.iem.at wrote:
From: Roman Haefeli reduzent@gmail.com To: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] glitches when streaming UDP Message-ID: 1517306864.2068.8.camel@gmail.com Content-Type: text/plain; charset="utf-8"
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
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Die, 2018-01-30 at 16:38 +0100, Dan Wilcox wrote:
It might be a scheduling issue with the kernel, realtime settings, crappy networking driver, etc.
I'm talking as an outside observer of a black box with limited understanding what's going on inside the box, so please bear with me when I'm talking bullshit.
It seems I simply need to keep the CPU busy with something like:
yes > /dev/null &
I need to run this four times, because I have four cores. The CPU goes hot, the fan makes noise, but Pd is glitch-free ;-)
Interestingly, setting CPU scaling governor to performance is not enough for Pd (it is for other applications, though). When doing that for each core, they all run at maximum speed. However, it doesn't help with making Pd glitch free. I really have to put some load on them.
This confirms what I suspected for while now: The advanced power saving features of modern CPUs don't really help for realtime audio.
I wonder what softwares like Ardour do differently to not fall victim of aggressive power saving.
Having a constantly running fan is also not an ideal situation. I don't care about increased power consumption at this point. Maybe there is a less invasive way to keep the CPU busy?
Roman
On Die, 2018-01-30 at 22:14 +0100, Roman Haefeli wrote:
It seems I simply need to keep the CPU busy with something like:
yes > /dev/null &
I need to run this four times, because I have four cores.
Actually, when setting the affinity of pd and burnMX to the same core, I don't need to burn cycles of the three other cores and still get glitch-free audio from Pd. Thanks, Katja, for the inspiration :-)
Roman
On Mit, 2018-01-31 at 01:30 +0100, Roman Haefeli wrote:
On Die, 2018-01-30 at 22:14 +0100, Roman Haefeli wrote:
It seems I simply need to keep the CPU busy with something like:
yes > /dev/null &
I need to run this four times, because I have four cores.
Actually, when setting the affinity of pd and burnMX to the same core,
Nah, burnMMX or burnBX and brothers don't even work well (still glitches). The only true help in this - as strange as it may sound - is indeed:
'taskset 0x00000001 yes > /dev/null'
"Yay" to the author of yes. What a useful software :-)
Roman
-
Dan Wilcox -
Roman Haefeli