[PD] glitches when streaming UDP

Martin Peach chakekatzil at gmail.com
Wed Feb 7 15:46:41 CET 2018


On Wed, Feb 7, 2018 at 9:26 AM, Roman Haefeli <reduzent at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180207/81279c15/attachment-0001.html>


More information about the Pd-list mailing list