Re: [PD] [solved] glitches when streaming UDP

[katja]

On Wed, Jan 31, 2018 at 9:32 AM, katja  wrote:

>
>
> On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli  wrote:
>
>>
>>
>> I'm a bit unsure about the -nosleep option. What is it supposed to do?
>> I thought it would make Pd burn as many CPU cycles as it can get. And
>> your mail from 2015 suggests a similar behavior. I run it like this:
>>
>> pd -noprefs -nosleep -rt -jack -channels 2
>>
>> and it still only runs at 3% of a core with the [adc~]-[dac~] patch.
>> This is with Pd-0.48-1 (git 3417d9036).
>>
>
> When running pd Pd-0.48-1 with option -nosleep on my core2 machine, CPU
> load is 100% on one (switching) core. Seems like the -nosleep option does
> not have the same effect on all hardware. That may be an indicator of the
> underlying problem causing audio drop out.
>

Sorry, forgot to mention that this is with Xubuntu 16.04.


> Katja
>
>
>
>> Roman
>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[katja]

On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli  wrote:

>
>
> I'm a bit unsure about the -nosleep option. What is it supposed to do?
> I thought it would make Pd burn as many CPU cycles as it can get. And
> your mail from 2015 suggests a similar behavior. I run it like this:
>
> pd -noprefs -nosleep -rt -jack -channels 2
>
> and it still only runs at 3% of a core with the [adc~]-[dac~] patch.
> This is with Pd-0.48-1 (git 3417d9036).
>

When running pd Pd-0.48-1 with option -nosleep on my core2 machine, CPU
load is 100% on one (switching) core. Seems like the -nosleep option does
not have the same effect on all hardware. That may be an indicator of the
underlying problem causing audio drop out.

Katja



> Roman
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[Roman Haefeli]

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 0x0001 yes > /dev/null'

"Yay" to the author of yes. What a useful software :-)

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[Roman Haefeli]

On Mit, 2018-01-31 at 00:49 +0100, katja wrote:
> Found this in the archives, maybe it is somewhat similar: in the
> early Raspberry Pi days core switching seemed to be a problem for Pd
> and it could be solved by using 'taskset'.

Thanks for the -nosleep and the core affinity suggestion. I tried both
and they don't seem to make a difference. 

I'm a bit unsure about the -nosleep option. What is it supposed to do?
I thought it would make Pd burn as many CPU cycles as it can get. And
your mail from 2015 suggests a similar behavior. I run it like this:

pd -noprefs -nosleep -rt -jack -channels 2

and it still only runs at 3% of a core with the [adc~]-[dac~] patch.
This is with Pd-0.48-1 (git 3417d9036).

Roman





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[katja]

Found this in the archives, maybe it is somewhat similar: in the early
Raspberry Pi days core switching seemed to be a problem for Pd and it could
be solved by using 'taskset'. See:

https://lists.puredata.info/pipermail/pd-list/2015-02/109189.html

The CPU switching problem went away 'by itself' after a Raspbian update,
but it was probably hardware specific.

On Wed, Jan 31, 2018 at 12:31 AM, katja  wrote:

> What happens when running Pd with option -nosleep? I vaguely remember
> having problems with CPU scaling which could be 'resolved' with that
> option. People smarter than me pointed to other solutions where you could
> reserve a specific core for the Pd process. But I'm unable to retrieve that
> information.
>
> On Wed, Jan 31, 2018 at 12:08 AM, Roman Haefeli 
> wrote:
>
>> On Die, 2018-01-30 at 23:31 +0100, Dan Wilcox wrote:
>> > I agree. I recorded 8 channel multitrack from Pd to Ardour using a
>> > single core Thinkpad back in the day with no drop outs.
>> >
>> > You could try running Pd with a different nice level. Even though it
>> > has "realtime priority" it sometimes helps to cue the scheduler a
>> > little more directly.
>>
>> 'pd -rt -jack' runs with a nice level of 0, so does jackd and ardour. I
>> tried giving it higher priority up (or should I say: down?) to -10, but
>> it didn't change the situation. Also, it seems  to me that it's not a
>> problem of priorities between several processes. The fact that burning
>> CPU cycles with _another_ process helps makes me think the problem
>> rather is that resources are not made ready quickly enough.
>>
>> Roman
>>
>>
>> > > On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
>> > >
>> > > 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?
>> > 
>> > Dan Wilcox
>> > @danomatika
>> > danomatika.com
>> > robotcowboy.com
>> >
>> >
>> >
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[katja]

What happens when running Pd with option -nosleep? I vaguely remember
having problems with CPU scaling which could be 'resolved' with that
option. People smarter than me pointed to other solutions where you could
reserve a specific core for the Pd process. But I'm unable to retrieve that
information.

On Wed, Jan 31, 2018 at 12:08 AM, Roman Haefeli  wrote:

> On Die, 2018-01-30 at 23:31 +0100, Dan Wilcox wrote:
> > I agree. I recorded 8 channel multitrack from Pd to Ardour using a
> > single core Thinkpad back in the day with no drop outs.
> >
> > You could try running Pd with a different nice level. Even though it
> > has "realtime priority" it sometimes helps to cue the scheduler a
> > little more directly.
>
> 'pd -rt -jack' runs with a nice level of 0, so does jackd and ardour. I
> tried giving it higher priority up (or should I say: down?) to -10, but
> it didn't change the situation. Also, it seems  to me that it's not a
> problem of priorities between several processes. The fact that burning
> CPU cycles with _another_ process helps makes me think the problem
> rather is that resources are not made ready quickly enough.
>
> Roman
>
>
> > > On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
> > >
> > > 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?
> > 
> > Dan Wilcox
> > @danomatika
> > danomatika.com
> > robotcowboy.com
> >
> >
> >
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[Roman Haefeli]

On Die, 2018-01-30 at 23:31 +0100, Dan Wilcox wrote:
> I agree. I recorded 8 channel multitrack from Pd to Ardour using a
> single core Thinkpad back in the day with no drop outs.
> 
> You could try running Pd with a different nice level. Even though it
> has "realtime priority" it sometimes helps to cue the scheduler a
> little more directly.

'pd -rt -jack' runs with a nice level of 0, so does jackd and ardour. I
tried giving it higher priority up (or should I say: down?) to -10, but
it didn't change the situation. Also, it seems  to me that it's not a
problem of priorities between several processes. The fact that burning
CPU cycles with _another_ process helps makes me think the problem
rather is that resources are not made ready quickly enough.

Roman    


> > On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
> > 
> > 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?
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [solved] glitches when streaming UDP

[Dan Wilcox]

I agree. I recorded 8 channel multitrack from Pd to Ardour using a single core 
Thinkpad back in the day with no drop outs.

You could try running Pd with a different nice level. Even though it has 
"realtime priority" it sometimes helps to cue the scheduler a little more 
directly.

> On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
> 
> 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?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [solved] glitches when streaming UDP

[Roman Haefeli]

> 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



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list