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. It has to be running with the audio, since the audio is being re-mixed in real time. 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
last 6 months has been for nothing. Pah!
Ed
fgmasdr IOhannes
[1] btw, it's usually really easy to check things: e.g. running your patch with "-nogui" and see whether you get dropouts might take about the same time as (you) asking on this list, (me) answering on this list and (you) reading the answer - not counting the delay due to amil-servers and the like. anyhow.