[PD] glitches when streaming UDP
reduzent at gmail.com
Wed Feb 7 15:26:40 CET 2018
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
> be to look into CPU scaling stuff when using Pd. The fact that an
> 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
> lot... On my previous laptop I could set various governors on my
> one there is only powersave and performance, the latter should work,
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part
More information about the Pd-list