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-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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
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 reduzent@gmail.com 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-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
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 katjavetter@gmail.com 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 reduzent@gmail.com 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-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/li stinfo/pd-list
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
On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli reduzent@gmail.com 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
On Wed, Jan 31, 2018 at 9:32 AM, katja katjavetter@gmail.com wrote:
On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli reduzent@gmail.com 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
On Mit, 2018-01-31 at 09:32 +0100, katja wrote:
On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli reduzent@gmail.com 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.
I just figured out now that -nosleep indeed works, also on my hardware. But it does _not_ when using -jack backend. Can anyone confirm?
That may be an indicator of the underlying problem causing audio drop out.
Definitely. I wonder how Pd is different from other jack clients.
Roman
I think it should still work, as long as you're polling jack and not using callbacks. (That should be a choice on the audio settings panel).
cheers Miller
On Thu, Feb 01, 2018 at 04:57:28PM +0100, Roman Haefeli wrote:
On Mit, 2018-01-31 at 09:32 +0100, katja wrote:
On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli reduzent@gmail.com 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.
I just figured out now that -nosleep indeed works, also on my hardware. But it does _not_ when using -jack backend. Can anyone confirm?
That may be an indicator of the underlying problem causing audio drop out.
Definitely. I wonder how Pd is different from other jack clients.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
katja -
Miller Puckette -
Roman Haefeli