Re: Help needed with a sync-problem

On Fri, Aug 3, 2012 at 8:27 PM, Peter van der Noord
<peterdunord@gmail.com>wrote:

> Well, that's pretty sad news. If this is the case, i'm afraid my
> involvement with the API ends here, since i can't work around this (unless
> someone has some good suggestions). I'm not into the lowerlevel mechanics
> of the implementation, but i don't understand why the rest of the graph
> can't (or shouldn't) wait for the custom-nodes to finish, what use is there
> to supply the use of custom nodes if they add incremental lag.


One tedious workaround is to "compensate" the lag by (I assume you already
have your own wrapper of the API which makes this a bit easier) adding
pass-through JavaScriptNodes to the points where the two connections need
to be in sync.

For example: http://i.imgur.com/wwRtl.png


>
> 2012/8/3 Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
>
>> It's a known and major issue all right, but it's not a bug. There's not
>> much that can be done about it though, afaict. The processing thread has to
>> buffer enough data (the buffer size) from the inputs of the JSNode before
>> its callback can be invoked, and next it just sends an event to the JS
>> thread to process the buffer. The audio thread, however, can't wait for the
>> JS thread to process the buffer but instead plays back the previously
>> processed buffer.
>>
>> This is one of the reasons why I think we should focus on empowering the
>> JS node / DSP API. If you want to add any custom processing to the graph,
>> you're going to have to adjust the rest of the graph accordingly and you'll
>> end up with more latency. This means that if you want to do extensive
>> custom processing you'll probably need to work around the graph or just go
>> with just the JS and have your own routing which means you're in a much
>> more flexible place already anyway. I think the graph serves best as an IO
>> abstraction, and that's the part we should focus on.
>>
>> Cheers,
>> Jussi
>>
>>
>> On Fri, Aug 3, 2012 at 4:16 PM, Peter van der Noord <
>> peterdunord@gmail.com> wrote:
>>
>>> Well, it seems indeed that custom-nodes add a delay-time to the signal.
>>> I've connected a few bypass modules (they write their input to the output)
>>> and i'm magically creating an echo...
>>>
>>> http://www.petervandernoord.nl/patchwork_js/?patch=2&buffer_size=8192
>>>
>>> (to hear sound, you have to select the loaded buffer from the pulldown
>>> in the buffersource-module)
>>>
>>> I'm getting somewhat confused and concerned about this, why does this
>>> happen and isn't this a major bug/issue?
>>>
>>> Peter
>>>
>>>
>>>
>>> 2012/8/2 Adam Goode <agoode@google.com>
>>>
>>>> I think you can use playbackTime to determine the absolute a-rate time
>>>> of the beginning of the javascript buffer. But last I checked it wasn't
>>>> present in webkit.
>>>>
>>>> You might be able to count samples, assuming you know the node's noteOn
>>>> time, to keep track of the a-rate time. But with a short buffer size,
>>>> sometimes you can have problems as you've noticed.
>>>>
>>>>
>>>> On Thu, Aug 2, 2012 at 4:47 PM, Peter van der Noord <
>>>> peterdunord@gmail.com> wrote:
>>>>
>>>>> Ermmm.....wait, what? And that is intened behavior?
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> 2012/8/2 Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
>>>>>
>>>>>> Hey Peter!
>>>>>>
>>>>>> I think this is because the JSNode has a delay equivalent to the
>>>>>> buffer size, hence if you have parallel graphs that contain a different
>>>>>> number of JSNodes, they will arrive to the common destination at a
>>>>>> different delay.
>>>>>>
>>>>>> Cheers,
>>>>>> Jussi
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 2, 2012 at 11:35 PM, Peter van der Noord <
>>>>>> peterdunord@gmail.com> wrote:
>>>>>>
>>>>>>> I'm having a strange problem with some signals at the moment and
>>>>>>> i've been staring at it for way too long now, so i thought: why not put it
>>>>>>> up here, maybe someone sees what's going on. It's a lenghty story, so if
>>>>>>> you want to hang on...i'll try to explain :)
>>>>>>>
>>>>>>> As you may know, i'm writing a modular synthesizer:
>>>>>>>
>>>>>>> http://petervandernoord.nl/patchwork_js (maybe clear your cache if
>>>>>>> you've been there before)
>>>>>>>
>>>>>>> If you click the 'json to patch' button, a testpatch will be set.
>>>>>>> (Important to know: all custom nodes will be created with the buffer-size
>>>>>>> that's selected in the pulldown on the right). The patch contains 3 modules
>>>>>>> (in patchwork, a module can contain one or more audionodes, with the
>>>>>>> module's in/outputs mapped to certain in/outputs of the containing nodes):
>>>>>>>
>>>>>>> - The destination, which contains a normal destinationNode
>>>>>>> http://localhost/patchworkjs/js/modules/DestinationModule.js
>>>>>>>
>>>>>>> - a clockmodule. one custom js node
>>>>>>> http://localhost/patchworkjs/js/modules/DestinationModule.js
>>>>>>>
>>>>>>> - a triggersequencer, also one custom node.
>>>>>>> http://localhost/patchworkjs/js/modules/TriggerSequencerModule.js(the audioprocess callback is at the bottom)
>>>>>>>
>>>>>>> What is happening in the patch: the clock sends out single values
>>>>>>> of 1s (all other values are 0) on a given interval (set in BPM). The
>>>>>>> sequencer checks on every incoming value if that value is >0 AND the
>>>>>>> previous one was <=0 (i'll call that a clock-pulse). If that is the case,
>>>>>>> its SequencerParameter will proceed to the next step. A sequencer-parameter
>>>>>>> (actually it is a LogicSequencerParameter, but that's almost the same - it
>>>>>>> has one extra method) can be found here:
>>>>>>>
>>>>>>> http://localhost/patchworkjs/js/params/SequenceParameter.js
>>>>>>>
>>>>>>> It's basically just an array filled ith 0s and 1s (you can set a 1
>>>>>>> by clicking somewhere on the sequencer), and increases the current position
>>>>>>> when it gets a next() command. So, back to the the sequencer module: If it
>>>>>>> received a clock-pulse, it proceeds the sequencer. Then, if the (new) value
>>>>>>> of the sequencer-parameter is 1, the sequencer will write a 1 in its
>>>>>>> outputbuffer as well.
>>>>>>>
>>>>>>> My issues:
>>>>>>> - in the testpatch, both the clockmodule and the seq-module are
>>>>>>> connected to the output. if you activate some steps in the sequencer, you
>>>>>>> will hear that the clicks do not run in sync. I have no idea why that is,
>>>>>>> the stepsequencer writes a 1 in exact the same iteration as it reads the
>>>>>>> incoming 1s from the clock. In my opinion, they should run exactly in sync.
>>>>>>> - When you change the buffersize (which is for the customnodes) you
>>>>>>> will hear that the timedifference between the ticks changes (since there's
>>>>>>> no clear, you have to refresh the page, set another buffersize and click
>>>>>>> 'json to patch')
>>>>>>> - Something else i noticed: when i run just a clock module connected
>>>>>>> to the output, with a very low buffersize (256, 512), the clock seems to
>>>>>>> run very, very irregular.
>>>>>>>
>>>>>>>
>>>>>>> So, my main question: Does anyone have any idea why those two
>>>>>>> modules do not run in sync when both connected to the output?
>>>>>>>
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>