Even though you don't have audio coming out when you're muting, you're still doing dsp. You should put each channel in a sub patch or abstraction and use [switch~] to enable/disable that abstraction. This is super important with low resource machines. The best fix is to do a quick (10-5ms) fade in/out when muting/unmuting, then hit [switch~] so you don't get any clicks:
On May 5, 2013, at 12:12 PM, pd-list-request@iem.at wrote:
From: Halfdan Mouritzen halfdan@robothangarskib.dk Subject: [PD] High CPU usage when tracks are muted (Raspberry Pi) Date: May 5, 2013 12:11:56 PM EDT To: pd-list pd-list@iem.at
Dear PD Friends,
We are building a collaborative music sculpture, using five Raspberry Pi's to each run a seperate instrument / HID. Everything is very well, they each run a minimal Arch installation and boot up into PD without a GUI.
One machine we are building at the moment, is just a very basic sample player - it has 8 tables with samples, that get played via a looping tabplay~. The machine works by simply muting and unmuting of the different channels - very basic.
Now the problem is that when all eight tracks are unmuted the CPU usage is around 15-16 % - very fine, with lots of room for other activities. NOW, when one mutes channels, the CPU usage starts climbing and climbing, resulting in 95-100% usage when all the channels are muted... This results in lagging/glitching, when one tries to turn on channels again. The muting / unmuting is done through a simple *~ which gets set to either 0 or 1 with a line.
I have noticed others have experienced this problem, but I haven't been able to find a solution to the problem. Hope somebody has a solution, as we are installing the machine at a music festival this week, and plan to open source all patches/sounds/build plans etc.
All the best and keep on patching Halfdan & Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 5 May 2013 18:42, Dan Wilcox danomatika@gmail.com wrote:
Even though you don't have audio coming out when you're muting, you're still doing dsp.
Yes, what I don't understand though is _why_ we see such an increase in CPU load, when the channels are muted.
You should put each channel in a sub patch or abstraction and use [switch~] to enable/disable that abstraction. This is super important with low resource machines. The best fix is to do a quick (10-5ms) fade in/out when muting/unmuting, then hit [switch~] so you don't get any clicks:
The tracks are already seperated into abstractions, so this will be easy to implement.
Since the help for switch~ displays block~-help, I had mistaken the switch~ object as controlling blocksize as well.
I will implement your suggestions straight away - thanks!
Halfdan
On 2013-05-05 13:52, Halfdan Mouritzen wrote:
Yes, what I don't understand though is _why_ we see such an increase in CPU load, when the channels are muted.
Could it be that denormals are produced when the line gets close to 0? Depending on how the floating point is set up that could cause a lot of context switching. What happens if you fade to 0.001 instead of 0?
Martin
Yep good call, maybe a Pd update might fix it (pre-compiled version for RPi on Miller's webpage http://crca.ucsd.edu/~msp/software.html )
as from 0.44-2 the denormal thing has (apparently) been sorted.
On 5 May 2013 18:58, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-05 13:52, Halfdan Mouritzen wrote:
Yes, what I don't understand though is _why_ we see such an increase in CPU load, when the channels are muted.
Could it be that denormals are produced when the line gets close to 0? Depending on how the floating point is set up that could cause a lot of context switching. What happens if you fade to 0.001 instead of 0?
Martin
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
This might be the wrong direction but for a multichannel installation I has great success with Eric Lyon's player~ abstraction in his pd potpourri set. Not sure if it will work since its an external but I had 20+ players firing off and never had a glitch.
Cheers~ pp
On May 5, 2013, at 2:37 PM, "Julian Brooks" <jbeezez@gmail.commailto:jbeezez@gmail.com> wrote:
Yep good call, maybe a Pd update might fix it (pre-compiled version for RPi on Miller's webpage http://crca.ucsd.edu/~msp/software.html )
as from 0.44-2 the denormal thing has (apparently) been sorted.
On 5 May 2013 18:58, Martin Peach <martin.peach@sympatico.camailto:martin.peach@sympatico.ca> wrote: On 2013-05-05 13:52, Halfdan Mouritzen wrote:
Yes, what I don't understand though is _why_ we see such an increase in CPU load, when the channels are muted.
Could it be that denormals are produced when the line gets close to 0? Depending on how the floating point is set up that could cause a lot of context switching. What happens if you fade to 0.001 instead of 0?
Martin
Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Son, 2013-05-05 at 12:42 -0400, Dan Wilcox wrote:
Even though you don't have audio coming out when you're muting, you're still doing dsp. You should put each channel in a sub patch or abstraction and use [switch~] to enable/disable that abstraction. This is super important with low resource machines. The best fix is to do a quick (10-5ms) fade in/out when muting/unmuting, then hit [switch~] so you don't get any clicks:
this part:
[unpack f f] | / [del ] | [switch~]
is most likely not doing what you are expecting it to do. A [delay] outputs only bangs and no numbers. [switch~ ], however, will only compute one block when banged.
Also the [unpack]-[del] combination is weird as it first sets the delay time to 5 and then immediately to 1 or 0 (depending on which message got banged). Also, you don't want to apply the delay to both messages. When fading in, computation must be already turned on. The delay is only required for the fade-out.
I modified slightly to what I think you meant to do.
Roman
I made this little helper abstraction for dealing with fades/switches at the same time. You can specify the ramp up/down time and even add a delay before sending the ramp. I find it use it everywhere now.
Maybe someone will find it useful
Cheers, Joe
On 5 May 2013 20:48, Roman Haefeli reduzent@gmail.com wrote:
On Son, 2013-05-05 at 12:42 -0400, Dan Wilcox wrote:
Even though you don't have audio coming out when you're muting, you're still doing dsp. You should put each channel in a sub patch or abstraction and use [switch~] to enable/disable that abstraction. This is super important with low resource machines. The best fix is to do a quick (10-5ms) fade in/out when muting/unmuting, then hit [switch~] so you don't get any clicks:
this part:
[unpack f f] | / [del ] | [switch~]
is most likely not doing what you are expecting it to do. A [delay] outputs only bangs and no numbers. [switch~ ], however, will only compute one block when banged.
Also the [unpack]-[del] combination is weird as it first sets the delay time to 5 and then immediately to 1 or 0 (depending on which message got banged). Also, you don't want to apply the delay to both messages. When fading in, computation must be already turned on. The delay is only required for the fade-out.
I modified slightly to what I think you meant to do.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I had the same problem with cpu usage peaking when the patch was silent on the rpi with pd 0.43-something (whatever was in the standard rpi repos) Turned out it was the [hip~] that was causing the problem. (I used two [hip~ 5] before the [dac~] and simply removing them completely solved the problem)
The [hip~] bug might be solved in the 0.44-3 though I have not tested it yet.
.kristofer
On May 5, 2013, at 18:42 , Dan Wilcox danomatika@gmail.com wrote:
Even though you don't have audio coming out when you're muting, you're still doing dsp. You should put each channel in a sub patch or abstraction and use [switch~] to enable/disable that abstraction. This is super important with low resource machines. The best fix is to do a quick (10-5ms) fade in/out when muting/unmuting, then hit [switch~] so you don't get any clicks: <Screen Shot 2013-05-05 at 12.40.14 PM.png> On May 5, 2013, at 12:12 PM, pd-list-request@iem.at wrote:
From: Halfdan Mouritzen halfdan@robothangarskib.dk Subject: [PD] High CPU usage when tracks are muted (Raspberry Pi) Date: May 5, 2013 12:11:56 PM EDT To: pd-list pd-list@iem.at
Dear PD Friends,
We are building a collaborative music sculpture, using five Raspberry Pi's to each run a seperate instrument / HID. Everything is very well, they each run a minimal Arch installation and boot up into PD without a GUI.
One machine we are building at the moment, is just a very basic sample player - it has 8 tables with samples, that get played via a looping tabplay~. The machine works by simply muting and unmuting of the different channels - very basic.
Now the problem is that when all eight tracks are unmuted the CPU usage is around 15-16 % - very fine, with lots of room for other activities. NOW, when one mutes channels, the CPU usage starts climbing and climbing, resulting in 95-100% usage when all the channels are muted... This results in lagging/glitching, when one tries to turn on channels again. The muting / unmuting is done through a simple *~ which gets set to either 0 or 1 with a line.
I have noticed others have experienced this problem, but I haven't been able to find a solution to the problem. Hope somebody has a solution, as we are installing the machine at a music festival this week, and plan to open source all patches/sounds/build plans etc.
All the best and keep on patching Halfdan & Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I had the same problem with cpu usage peaking when the patch was silent on the rpi with pd 0.43-something (whatever was in the standard rpi repos) Turned out it was the [hip~] that was causing the problem. (I used two [hip~ 5] before the [dac~] and simply removing them completely solved the problem)
The [hip~] bug might be solved in the 0.44-3 though I have not tested it yet.
Unfortunately my raspberrys are packed into boxes right now, so I can't test.
During next week they will be back with me and I continue working on the setup - looking forward to testing your tip!
// Halfdan
-
Dan Wilcox -
Halfdan Mouritzen -
Joe White -
Julian Brooks -
Kristofer Hagbard -
Martin Peach -
Pagano, Patrick -
Roman Haefeli