Hey all
It's a well know issue and the solution has been discussed many times: When you're using audio and Gem rendering, it's wise to separate those two into their own instance of Pd.
I'm working on a project that does both, audio processing and Gem rendering. The OpenGL rendering is very light-weight and does only require minimal resources. Also the audio part uses a fraction of the available CPU power. What I observe is that I get a zipping noise for ~15 seconds, then clean audio for another 15 seconds before the zipping noise returns. The zipping noise occurs only when Gem rendering is turned on.
To me it looks like the problem is not related to limited resources, rather it seems that both, OpenGL and audio rendering, are tied to their respective clock and those clocks are not coupled and thus are not completely in sync.
I know I could put both parts into their own instances of Pd and that's what I'll do if there is no resolution, but for convenience reasons I'd prefer to have only one patch in one instance of Pd. Now, is there a way to loosen the coupling to OpenGL clock (is it the same as the monitor clock?) so that audio is not affected? I don't care about any side-effects like tearing (it won't be visible anyway for the kind of image).
Roman
On Thu, 2016-03-31 at 11:13 +0200, Roman Haefeli wrote:
Hey all
It's a well know issue and the solution has been discussed many times: When you're using audio and Gem rendering, it's wise to separate those two into their own instance of Pd.
I'm working on a project that does both, audio processing and Gem rendering. The OpenGL rendering is very light-weight and does only require minimal resources. Also the audio part uses a fraction of the available CPU power. What I observe is that I get a zipping noise for ~15 seconds, then clean audio for another 15 seconds before the zipping noise returns. The zipping noise occurs only when Gem rendering is turned on.
To me it looks like the problem is not related to limited resources, rather it seems that both, OpenGL and audio rendering, are tied to their respective clock and those clocks are not coupled and thus are not completely in sync.
I know I could put both parts into their own instances of Pd and that's what I'll do if there is no resolution, but for convenience reasons I'd prefer to have only one patch in one instance of Pd. Now, is there a way to loosen the coupling to OpenGL clock (is it the same as the monitor clock?) so that audio is not affected? I don't care about any side-effects like tearing (it won't be visible anyway for the kind of image).
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Roman
Le 31/03/2016 11:19, Roman Haefeli a écrit :
On Thu, 2016-03-31 at 11:13 +0200, Roman Haefeli wrote:
Hey all
It's a well know issue and the solution has been discussed many times: When you're using audio and Gem rendering, it's wise to separate those two into their own instance of Pd.
I'm working on a project that does both, audio processing and Gem rendering. The OpenGL rendering is very light-weight and does only require minimal resources. Also the audio part uses a fraction of the available CPU power. What I observe is that I get a zipping noise for ~15 seconds, then clean audio for another 15 seconds before the zipping noise returns. The zipping noise occurs only when Gem rendering is turned on.
To me it looks like the problem is not related to limited resources, rather it seems that both, OpenGL and audio rendering, are tied to their respective clock and those clocks are not coupled and thus are not completely in sync.
I know I could put both parts into their own instances of Pd and that's what I'll do if there is no resolution, but for convenience reasons I'd prefer to have only one patch in one instance of Pd. Now, is there a way to loosen the coupling to OpenGL clock (is it the same as the monitor clock?) so that audio is not affected? I don't care about any side-effects like tearing (it won't be visible anyway for the kind of image).
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
cheers c
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.
One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.
On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)?
I
guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm not sure I understand [pd~]. Consider: [foo~]|[pd~] <-- some dsp stuff going on in here |[cpu_hungy_hippo~] How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences. One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance. On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs? Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000 To: brbrofsvl@gmail.com; reduzent@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd From: pd-list@lists.iem.at
I'm not sure I understand [pd~]. Consider: [foo~]|[pd~] <-- some dsp stuff going on in here |[cpu_hungy_hippo~] How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote: One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
#yiv7276929600 #yiv7276929600 --.yiv7276929600hmmessage P{margin:0px;padding:0px;}#yiv7276929600 body.yiv7276929600hmmessage{font-size:12pt;font-family:Calibri;}#yiv7276929600 Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs? Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000 To: brbrofsvl@gmail.com; reduzent@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd From: pd-list@lists.iem.at
I'm not sure I understand [pd~]. Consider: [foo~]|[pd~] <-- some dsp stuff going on in here |[cpu_hungy_hippo~] How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences. One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance. On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Anyway, isn't it that a way to use other cores?
Im not an expert but “send output before “ couldnt be really "before" but “now” or parallel "now".
Btw, I never used [pd~]
Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 01:24:55 +0000 From: jancsika@yahoo.com To: lucarda27@hotmail.com; pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs?Mensaje telepatico asistido por maquinas.Date: Fri, 1 Apr 2016 00:37:26 +0000To: brbrofsvl@gmail.com; reduzent@gmail.comCC: pd-list@lists.iem.atSubject: Re: [PD] DSP and Gem in the same instance of PdFrom: pd-list@lists.iem.atI'm not sure I understand [pd~]. Consider:[foo~]|[pd~] <-- some dsp stuff going on in here|[cpu_hungy_hippo~]How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?And in general, how is the super-process able to anything other than block when waiting for output from [pd~]? -Jonathan On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote: One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Further more if you have 300 calculations to do in a given time and you split somehow those calculations in 2 calculators you have more chances not to exceed 1 calculator limits. Even overheat 1 calculator.
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: jancsika@yahoo.com; pd-list@lists.iem.at Date: Fri, 1 Apr 2016 01:45:29 +0000 Subject: Re: [PD] DSP and Gem in the same instance of Pd
Anyway, isn't it that a way to use other cores?
Im not an expert but “send output before “ couldnt be really "before" but “now” or parallel "now".
Btw, I never used [pd~]
Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 01:24:55 +0000 From: jancsika@yahoo.com To: lucarda27@hotmail.com; pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs?Mensaje telepatico asistido por maquinas.Date: Fri, 1 Apr 2016 00:37:26 +0000To: brbrofsvl@gmail.com; reduzent@gmail.comCC: pd-list@lists.iem.atSubject: Re: [PD] DSP and Gem in the same instance of PdFrom: pd-list@lists.iem.atI'm not sure I understand [pd~]. Consider:[foo~]|[pd~] <-- some dsp stuff going on in here|[cpu_hungy_hippo~]How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?And in general, how is the super-process able to anything other than block when waiting for output from [pd~]? -Jonathan On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote: One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Right, so the point of [pd~] is that the OS can now throw whatever is going on in the subprocess onto another core. The idea from what I've heard for Gem is that you can leave the DSP off in the [pd~] instance, run Gem from there (on another core, possibly). Then if together they would have maxed out one core they could split the work among two and proceed in time.
But if the problem is that Gem has to wait for something to happen elsewhere before it can proceed, it won't help. Kind of in the same way that running an infinite [until] loop on the subprocess will halt the main process, too.
On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola < lucarda27@hotmail.com> wrote:
Isn`t
[pd~] <-- some dsp stuff going on in here
To take advantage of multi-core CPUs?
Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000 To: brbrofsvl@gmail.com; reduzent@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd From: pd-list@lists.iem.at
I'm not sure I understand [pd~]. Consider:
[foo~] | [pd~] <-- some dsp stuff going on in here | [cpu_hungy_hippo~]
How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.
One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.
On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)?
I
guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
And more, A single thread calculation divided between 2 cores in its 1 core time is more stable. 1 00 11 00 1 transistors have more idle time. Mensaje telepatico asistido por maquinas.
From: brbrofsvl@gmail.com Date: Thu, 31 Mar 2016 22:45:57 -0400 Subject: Re: [PD] DSP and Gem in the same instance of Pd To: jancsika@yahoo.com CC: lucarda27@hotmail.com; pd-list@lists.iem.at
Right, so the point of [pd~] is that the OS can now throw whatever is going on in the subprocess onto another core. The idea from what I've heard for Gem is that you can leave the DSP off in the [pd~] instance, run Gem from there (on another core, possibly). Then if together they would have maxed out one core they could split the work among two and proceed in time. But if the problem is that Gem has to wait for something to happen elsewhere before it can proceed, it won't help. Kind of in the same way that running an infinite [until] loop on the subprocess will halt the main process, too. On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote: But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs?Mensaje telepatico asistido por maquinas.Date: Fri, 1 Apr 2016 00:37:26 +0000To: brbrofsvl@gmail.com; reduzent@gmail.comCC: pd-list@lists.iem.atSubject: Re: [PD] DSP and Gem in the same instance of PdFrom: pd-list@lists.iem.atI'm not sure I understand [pd~]. Consider:[foo~]|[pd~] <-- some dsp stuff going on in here|[cpu_hungy_hippo~]How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?And in general, how is the super-process able to anything other than block when waiting for output from [pd~]? -Jonathan On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote: One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Slightly OT-- but related: I'm going to throw out a wish-list item which is probably impossible or very hard to implement,
Find a way for the DSP Graph compiler to naturally break up the task into small chunks, which all use shared memory in a thread-safe way, so that the PD job automagically spreads itself out over available cores without any special work by the programmer.
Now that I've got my big, fast, lots of ram, 6-core AMD box running again, I notice that I can run MUCH larger graphs there than on my Raspberry Pi.
But I think it's just a raw CPU speed, or Cache Speed, or speed to RAM which matters, and not the number of cores.
I notice that on my Pi there seems to be two processes, one for the GUI and one for the DSP. 2 cores are wasted unless I use the [pd~] object, and I have to basically guess how to split up the job.
I know, I'm dreaming here....
On Thu, Mar 31, 2016 at 10:57 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
And more,
A single thread calculation divided between 2 cores in its 1 core time is more stable.
1 0 0 1 1 0 0 1
transistors have more idle time.
Mensaje telepatico asistido por maquinas.
From: brbrofsvl@gmail.com Date: Thu, 31 Mar 2016 22:45:57 -0400 Subject: Re: [PD] DSP and Gem in the same instance of Pd To: jancsika@yahoo.com CC: lucarda27@hotmail.com; pd-list@lists.iem.at
Right, so the point of [pd~] is that the OS can now throw whatever is going on in the subprocess onto another core. The idea from what I've heard for Gem is that you can leave the DSP off in the [pd~] instance, run Gem from there (on another core, possibly). Then if together they would have maxed out one core they could split the work among two and proceed in time.
But if the problem is that Gem has to wait for something to happen elsewhere before it can proceed, it won't help. Kind of in the same way that running an infinite [until] loop on the subprocess will halt the main process, too.
On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola < lucarda27@hotmail.com> wrote:
Isn`t
[pd~] <-- some dsp stuff going on in here
To take advantage of multi-core CPUs?
Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000 To: brbrofsvl@gmail.com; reduzent@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd From: pd-list@lists.iem.at
I'm not sure I understand [pd~]. Consider:
[foo~] | [pd~] <-- some dsp stuff going on in here | [cpu_hungy_hippo~]
How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.
One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.
On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)?
I
guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think I mentioned before-- it sounds like what one would want here is another external that abstracts away the complexity of starting two Pd instances that communicate over a netreceive/netsend pair. I'm not sure how you'd emphasize the asynchronicity, though. -Jonathan
On Thursday, March 31, 2016 10:46 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
Right, so the point of [pd~] is that the OS can now throw whatever is going on in the subprocess onto another core. The idea from what I've heard for Gem is that you can leave the DSP off in the [pd~] instance, run Gem from there (on another core, possibly). Then if together they would have maxed out one core they could split the work among two and proceed in time. But if the problem is that Gem has to wait for something to happen elsewhere before it can proceed, it won't help. Kind of in the same way that running an infinite [until] loop on the subprocess will halt the main process, too. On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
But [cpu_hungry_hippo~] needs input from [pd~] in order to compute its output. So [pd~] must send output before [cpu_hungry_hippo~] can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
Isn`t [pd~] <-- some dsp stuff going on in here To take advantage of multi-core CPUs? Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000 To: brbrofsvl@gmail.com; reduzent@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] DSP and Gem in the same instance of Pd From: pd-list@lists.iem.at
I'm not sure I understand [pd~]. Consider: [foo~]|[pd~] <-- some dsp stuff going on in here |[cpu_hungy_hippo~] How does [pd~] help me in this case, as opposed to just putting the "dsp stuff" directly in the patch?
And in general, how is the super-process able to anything other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber brbrofsvl@gmail.com wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences. One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance. On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
Le 31/03/2016 11:19, Roman Haefeli a écrit :
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
Gem have no precedence over audio : they both have the same priority. when having priorities on audio, the openGL rendering did not have fixed frame rate, and it's not possible any-more to have smooth hight speed movement.
So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
one possible explanation of your problem is that you are rendering a 60 fps, and that openGL is sync on the 60fps screen. You can have jitter between the 2 different 60fps clock. If Gem is waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
if this is the cause of your problem, then reduce Gem fps to 59, or remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2016-03-31 at 17:13 -0400, Matt Barber wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.
In this particular case it wouldn't have helped, it would just have taken longer time until the drop-out occured. It seems setting gemwin to 60 fps makes Pd/Gem want to render slightly more often than the screen allows. No matter how much latency you give, it'll be eaten up soon.
Roman
One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.
On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli reduzent@gmail.com wrote: On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote: > > Le 31/03/2016 11:19, Roman Haefeli a écrit : > > > > BTW: Why does the graphics rendering|clock have precedence over the > > audio rendering (at least, it seems to be like that in Pure Data/Gem)? I > > guess most softwares do it the other way around, since clicks are much > > more noticeable than a frame being a few milliseconds late. > > Gem have no precedence over audio : they both have the same priority. > when having priorities on audio, the openGL rendering did not have > fixed frame rate, and it's not possible any-more to have smooth hight > speed movement. > > So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-) > one possible explanation of your problem is that you are rendering a > 60 fps, and that openGL is sync on the 60fps screen. > You can have jitter between the 2 different 60fps clock. If Gem is > waiting for the screen, then everything (including audio) is on pause. That is exactly what I was doing. > if this is the cause of your problem, then reduce Gem fps to 59, or > remove openGL syncro (sync to vblank). This is exactly what helped (reducing fps to 59). Thanks for your sharp thinking. Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2016-03-31 11:19, Roman Haefeli wrote:
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
it doesn't. both audio and graphics are running in the same thread. if anything in this thread locks for too long, you might get audible clicks.
now Gem is violating the first rule of realtime programming ("never do any system calls in a realtime thread")¹. Each frame (whenever the actual drawing is done) the gfx card will stall the Pd-thread for a short time. if the gfx-driver is configured to sync to vblank (to avoid tearing), then this short time might be considerably longer, as the thread is stalling until the next vblank (which might happen only 1/60s in the future). so turning off sync-to-vblank is a good start. but even so, the process might get stalled for a short(er) period. so the next thing to do is to raise Pd's system latency, so it buffers enough to cater for dropouts.
running Gem is a separate thread is not really feasible: (iirc) some frameworks Gem uses MUST run in the main thread.
other things to consider: depending on what you want to do, you might consider rendering "nothing" (e.g. if you are using Gem for motion tracking, there is no reason why you would need to display anything; since Gem requires a window to do anything, just make it super small and make sure to not call anything talks with the gfx-card (anything openGL). of course, this might totally not work for your project.
also: the "zipping noise" you describe might be something else than a "dropout". it might be that the noise is actually generated in the analog circuitry of your motherboard (e.g. on some systems i hear a zipper noise whenever i move the mouse; or display a certain pattern on the screen). if this is the case, try isolating the audio circuit from the video circuit, e.g. by outputting audio via toslink and using an external D/A-converter.
fgmasdr IOhannes
¹ Gem is not alone here. virtually all objects (there are of course exceptions, like [readsf~]) that do system calls (like reading a file) are not realtime safe. with most of these objects you can get away by only calling the non-realtime-safe operations during initialisation. With a realtime renderer, this is obivously not possible.
On Thu, 2016-03-31 at 11:46 +0200, IOhannes m zmoelnig wrote:
On 2016-03-31 11:19, Roman Haefeli wrote:
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
it doesn't.
Ok, good to know.
both audio and graphics are running in the same thread.
I was actually assuming they're in the same thread, but thought there are two different clocks. I realize now that setting [gemwin] to a frame rate of 60 is not sensible exactly because there is only one clock (the one from the audio card) and that you cannot render quicker than the monitor frame rate (at least not with sync-to-vblank, which seems logical). With a setting of 59 fps all glitches are gone and it seems Pd/Gem doesn't have to wait for the monitor to be ready.
if anything in this thread locks for too long, you might get audible clicks.
Yes.
now Gem is violating the first rule of realtime programming ("never do any system calls in a realtime thread")¹. Each frame (whenever the actual drawing is done) the gfx card will stall the Pd-thread for a short time.
My thinking was that when I set a high frame rate and and the graphic still runs smoothly, I can use an audio latency that is a little bit higher than the duration of one frame (total_latency = 1/fps + audio_setting_that_works_fine_without_Gem). Which I believe is still true, but _not_ when requesting a frame rate higher than monitor refresh rate.
if the gfx-driver is configured to sync to vblank (to avoid tearing), then this short time might be considerably longer, as the thread is stalling until the next vblank (which might happen only 1/60s in the future). so turning off sync-to-vblank is a good start. but even so, the process might get stalled for a short(er) period. so the next thing to do is to raise Pd's system latency, so it buffers enough to cater for dropouts.
Thanks for the detailed explanation.
running Gem is a separate thread is not really feasible: (iirc) some frameworks Gem uses MUST run in the main thread.
Not being an expert, I wouldn't have suggested it.
other things to consider: depending on what you want to do, you might consider rendering "nothing" (e.g. if you are using Gem for motion tracking, there is no reason why you would need to display anything; since Gem requires a window to do anything, just make it super small and make sure to not call anything talks with the gfx-card (anything openGL). of course, this might totally not work for your project.
Good to know. In that particular case something is displayed in the gemwin.
also: the "zipping noise" you describe might be something else than a "dropout". it might be that the noise is actually generated in the analog circuitry of your motherboard (e.g. on some systems i hear a zipper noise whenever i move the mouse; or display a certain pattern on the screen). if this is the case, try isolating the audio circuit from the video circuit, e.g. by outputting audio via toslink and using an external D/A-converter.
I consider myself able to discern analog circuitry noises from noises caused by DSP interruptions. In this case it was clearly drop-outs. But thanks for covering that aspect, too.
Roman
-
cyrille henry -
IOhannes m zmoelnig -
Jonathan Wilkes -
Lucas Cordiviola -
Matt Barber -
Roman Haefeli -
William Huston