[PD] Maybe I'm pushing dynamic object creation too far

[Roman Haefeli]

On Wed, 2011-02-02 at 23:25 +0000, Ed Kelly wrote:
> > On 2011-02-02 01:00, Ed Kelly wrote:
> 
> > > I get dropouts, regardless of the jack buffer size/buffers number. Is this 
> > > because the dynamic creation of a new object interrupts the pd audio stream? 
> >If 
> >
> > > so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) 
> >
> > > and 2. if so, can pd -nogui sort it out?
> 
> > the problem most likely comes from the DSP graph being continuously rebuilt.
> > the only things you can do for now is:
> > - - try to reduce rebuilding of the DSP graph as much as possible.
> > needeless to say that you shouldn't dynamically create objects that are
> > not needed.
> > more interesting is that e.g. creating 3 objects while audio is running,
> > will re-caculate the DSP graph 3 times. even if this happens in 0
> > logical time. so i you know you are going to schedule several
> > dynamically created objects "at once", turn audio off before and turn it
> > on again after you do the actual creation.
> 
> Dammit!
> Only one at a time, but they are tables of perhaps 300000 points. Then I copy 
> data from the input buffer into the table.

In your situation I'd try to do everything that doesn't necessarily need
to happen in 0 logical time to extend to > 0 logical time. Unless you
really need the new tables immediately after the buffer was filled, I'd
suggest to copy them over 'slowly'. One approach once mentioned by
Miller Puckette is to do array copying by doing it in the audio domain
within an upsampled sub-patch. This would make DSP drop-outs during
array copying much less likely.  

> It has to be running with the audio, since the audio is being re-mixed in real 
> time.

Wrong. Dynamic creation happens in 0 logical time. Now let's consider a
case where you dynamically create several objects in one go. After every
single object the DSP graph is recompiled. The real time this process
takes is quite high. Now if you'd first turn off DSP, create all
necessary objects dynamically and then turn DSP on again, the DSP graph
is recompiled once and the real time this takes is much shorter. If
you're lucky, it will be so short (shorter than your current audio
buffer setting), that you don't even notice a drop out. 

Just to make myself more clear: It's perfectly possible to turn DSP off
and on again in 0 logical time without noticing it at all, even when
there is some audio processing going on.


> Everything works fine if I'm using the onboard sound - e.g. OSS, but the 
> problems only happen when I switch to jack. Of course the onboard sound would be 
> OK if I was using only output, but the whole point is to live-sample the input. 
> The mic input on my laptop is really crappy.
> 
> > - - try to get the DSP graph building into a separate thread.
> > well, this involves pd~ or the like....
> 
> Dammit again - I'm using the second core of the machine for the live score, 
> dynamic object creation in GEM
>  - but I see the new version of Inscore supports PD, so all my work over the 
> last 6 months has been for nothing.

I wouldn't be too sure about that. Try to figure out what needs to
really happen in 0 logical time, since most often the problems of audio
drop outs is that Pd is requested too much to compute in 0 time. Try to
distribute as much as possible over time, so that as many things as
possible happen continuously and as little things as possible need to be
calculated instantly. 

Roman