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-request@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