Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39608 > unrolled thread

setTimeOut and lag adding up.

Back to article view | Back to comp.lang.javascript

Contents

  setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-10 08:41 -0800
    Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-10 08:46 -0800
      Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-10 09:01 -0800
      Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-10 09:31 -0800
        Re: setTimeOut and lag adding up. JJ <jj4public@gmail.com> - 2021-03-11 14:01 +0700
    Re: setTimeOut and lag adding up. Arno Welzel <usenet@arnowelzel.de> - 2021-03-11 12:57 +0100
      Re: setTimeOut and lag adding up. Silvio <silvio@internet.com> - 2021-03-11 14:17 +0100
        Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-11 06:07 -0800
          Re: setTimeOut and lag adding up. Silvio <silvio@internet.com> - 2021-03-11 16:03 +0100
            Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-11 07:47 -0800
      Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-11 05:54 -0800
      Re: setTimeOut and lag adding up. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-11 06:13 -0800

#39608 — setTimeOut and lag adding up.

I have a question i shift some 12 000 note events.
During 5 min 48 seconds.

That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000?????

Can that really be reasonable?
What is the main cause of it in this function?

function doPlayup() {
	if (keepGoing) {
		if (copyEv.length) {
			if (track[playtrack].midiMess[midEvent].data0<192 || track[playtrack].midiMess[midEvent].data0>207){
				noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1, track[playtrack].midiMess[midEvent].data2];
			} else {
				noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1];
			}
			outportarr[outportindex].send(noteMessage);
			//pianoKeypressOut();
			waittime = copyEv.shift();
			midEvent++;
			setTimeout(doPlayup, waittime);
		} else { stopPLAY();}
	}
}

[toc] | [next] | [standalone]

#39609

onsdag 10 mars 2021 kl. 17:41:11 UTC+1 skrev Jonas Thörnvall:
> I have a question i shift some 12 000 note events. 
> During 5 min 48 seconds. 
> 
> That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> 
> Can that really be reasonable? 
> What is the main cause of it in this function? 
> 
> function doPlayup() { 
> if (keepGoing) { 
> if (copyEv.length) { 
> if (track[playtrack].midiMess[midEvent].data0<192 || track[playtrack].midiMess[midEvent].data0>207){ 
> noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1, track[playtrack].midiMess[midEvent].data2]; 
> } else { 
> noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1]; 
> } 
> outportarr[outportindex].send(noteMessage); 
> //pianoKeypressOut(); 
> waittime = copyEv.shift(); 
> midEvent++; 
> setTimeout(doPlayup, waittime); 
> } else { stopPLAY();} 
> } 
> }
And i do have added up the intervals/timeouts to check they really add up to the 5.48 minutes.
But yet last note is played around 6.20 minutes.

[toc] | [prev] | [next] | [standalone]

#39610

onsdag 10 mars 2021 kl. 17:46:38 UTC+1 skrev Jonas Thörnvall:
> onsdag 10 mars 2021 kl. 17:41:11 UTC+1 skrev Jonas Thörnvall: 
> > I have a question i shift some 12 000 note events. 
> > During 5 min 48 seconds. 
> > 
> > That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> > 
> > Can that really be reasonable? 
> > What is the main cause of it in this function? 
> > 
> > function doPlayup() { 
> > if (keepGoing) { 
> > if (copyEv.length) { 
> > if (track[playtrack].midiMess[midEvent].data0<192 || track[playtrack].midiMess[midEvent].data0>207){ 
> > noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1, track[playtrack].midiMess[midEvent].data2]; 
> > } else { 
> > noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1]; 
> > } 
> > outportarr[outportindex].send(noteMessage); 
> > //pianoKeypressOut(); 
> > waittime = copyEv.shift(); 
> > midEvent++; 
> > setTimeout(doPlayup, waittime); 
> > } else { stopPLAY();} 
> > } 
> > }
> And i do have added up the intervals/timeouts to check they really add up to the 5.48 minutes. 
> But yet last note is played around 6.20 minutes.
I finally find something omitting the timeout?
output.send( [0x80, 60, 0x40], window.performance.now() + copyEv.shift );
Could this work you think?
But how do one wrap such a call, you can't use a loop?

[toc] | [prev] | [next] | [standalone]

#39611

onsdag 10 mars 2021 kl. 17:46:38 UTC+1 skrev Jonas Thörnvall:
> onsdag 10 mars 2021 kl. 17:41:11 UTC+1 skrev Jonas Thörnvall: 
> > I have a question i shift some 12 000 note events. 
> > During 5 min 48 seconds. 
> > 
> > That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> > 
> > Can that really be reasonable? 
> > What is the main cause of it in this function? 
> > 
> > function doPlayup() { 
> > if (keepGoing) { 
> > if (copyEv.length) { 
> > if (track[playtrack].midiMess[midEvent].data0<192 || track[playtrack].midiMess[midEvent].data0>207){ 
> > noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1, track[playtrack].midiMess[midEvent].data2]; 
> > } else { 
> > noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1]; 
> > } 
> > outportarr[outportindex].send(noteMessage); 
> > //pianoKeypressOut(); 
> > waittime = copyEv.shift(); 
> > midEvent++; 
> > setTimeout(doPlayup, waittime); 
> > } else { stopPLAY();} 
> > } 
> > }
> And i do have added up the intervals/timeouts to check they really add up to the 5.48 minutes. 
> But yet last note is played around 6.20 minutes.

So the timed send below...

output.send( [0x80, 60, 0x40], window.performance.now() + 1000.0 ); // Inlined array creation- note off, middle C,

seem to say send this note "after 1000 ms" on timer which is performance now.
So having the code with the waittime like above one would end up with something like.

if (track[playtrack].midiMess[midEvent].data0<192 || track[playtrack].midiMess[midEvent].data0>207){
noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1, track[playtrack].midiMess[midEvent].data2];
} else {
noteMessage = [track[playtrack].midiMess[midEvent].data0, track[playtrack].midiMess[midEvent].data1];
}
outportarr[outportindex.send(noteMessage,, window.performance.now() + waitime );
waittime = copyEv.shift();

But how "do one wrap such a call of code" sequense it until all evens shifted? You can not use a loop because javascript do not pause?
I am a bit lost with never programming paradigm.
I would be very happy if someone could tell me "how" because this latency issue have boggled me for years.

[toc] | [prev] | [next] | [standalone]

#39617

On Wed, 10 Mar 2021 09:31:13 -0800 (PST), Jonas Thörnvall wrote:
> I would be very happy if someone could tell me "how" because this latency
> issue have boggled me for years.

I highly recommend you learn how to debug a script. It'll considerably
shorten your project development time. Rather than having to wait for a
newgroup answer which may take days to come, or may never come at all.

[toc] | [prev] | [next] | [standalone]

#39618

Jonas Thörnvall:

> I have a question i shift some 12 000 note events.
> During 5 min 48 seconds.
> 
> That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000?????
> 
> Can that really be reasonable?

Yes. Because setTimeout() will start a timer at the point when it is
called. When the handler then needs 0.0025 seconds to deal with the
event before the next setTimeout() call is done this sums up to 30
seconds for 12000 events.

What you need is setInterval() and clearInterval():

<https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval>

<https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearInterval>


This call will cause a function to be called *exactly* every n
milliseconds, regardless how long this function will take to handle the
call. So also make sure that the function will not take longer than the
interval is.

Also keep in mind that you do NOT call setInterval() again! You call
that only ONCE to start the repeated interval calls and to stop it again
you use clearInterval() using the ID which you got from setInterval().


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39619

On 3/11/21 12:57 PM, Arno Welzel wrote:
> Jonas Thörnvall:
> 
>> I have a question i shift some 12 000 note events.
>> During 5 min 48 seconds.
>>
>> That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000?????
>>
>> Can that really be reasonable?
> 
> Yes. Because setTimeout() will start a timer at the point when it is
> called. When the handler then needs 0.0025 seconds to deal with the
> event before the next setTimeout() call is done this sums up to 30
> seconds for 12000 events.
> 
> What you need is setInterval() and clearInterval():
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval>
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearInterval>
> 
> 
> This call will cause a function to be called *exactly* every n
> milliseconds, regardless how long this function will take to handle the
> call. So also make sure that the function will not take longer than the
> interval is.
> 
> Also keep in mind that you do NOT call setInterval() again! You call
> that only ONCE to start the repeated interval calls and to stop it again
> you use clearInterval() using the ID which you got from setInterval().
> 
> 

There is no guarantee at all about the actual timings of calls 
dispatched via either setInterval or setTimeout. This is in essence no 
different from the promptness of event listeners. Apart from the fact 
that there is an underlying  timer interval that is nonzero (and bigger 
than 1ms, I have read that 4ms is typical) which makes exactly timed 
execution impossible any currently executing code can prevent the 
execution of scheduled calls indefinitely.

There is no way to solve the timing problem at this level. Only if the 
Midi subsystem implements it's own timing logic (which would totally 
make sense to me but I have no idea if it does) could sufficiently 
accurate audio timing be achieved.

[toc] | [prev] | [next] | [standalone]

#39621

torsdag 11 mars 2021 kl. 14:18:47 UTC+1 skrev Silvio:
> On 3/11/21 12:57 PM, Arno Welzel wrote: 
> > Jonas Thörnvall: 
> > 
> >> I have a question i shift some 12 000 note events. 
> >> During 5 min 48 seconds. 
> >> 
> >> That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> >> 
> >> Can that really be reasonable? 
> > 
> > Yes. Because setTimeout() will start a timer at the point when it is 
> > called. When the handler then needs 0.0025 seconds to deal with the 
> > event before the next setTimeout() call is done this sums up to 30 
> > seconds for 12000 events. 
> > 
> > What you need is setInterval() and clearInterval(): 
> > 
> > <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval> 
> > 
> > <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearInterval> 
> > 
> > 
> > This call will cause a function to be called *exactly* every n 
> > milliseconds, regardless how long this function will take to handle the 
> > call. So also make sure that the function will not take longer than the 
> > interval is. 
> > 
> > Also keep in mind that you do NOT call setInterval() again! You call 
> > that only ONCE to start the repeated interval calls and to stop it again 
> > you use clearInterval() using the ID which you got from setInterval(). 
> > 
> >
> There is no guarantee at all about the actual timings of calls 
> dispatched via either setInterval or setTimeout. This is in essence no 
> different from the promptness of event listeners. Apart from the fact 
> that there is an underlying timer interval that is nonzero (and bigger 
> than 1ms, I have read that 4ms is typical) which makes exactly timed 
> execution impossible any currently executing code can prevent the 
> execution of scheduled calls indefinitely. 
> 
> There is no way to solve the timing problem at this level. Only if the 
> Midi subsystem implements it's own timing logic (which would totally 
> make sense to me but I have no idea if it does) could sufficiently 
> accurate audio timing be achieved.

If i understand you correct Silivo you seem to say that the midi API simply not have the ability to generate iterative sends that are in sync with clock using the functionality that now within Javascript?
Or if i missunderstand you, what would you propose to do to get iterative sends in sync with clock?

Jonas

[toc] | [prev] | [next] | [standalone]

#39623

On 3/11/21 3:07 PM, Jonas Thörnvall wrote:
> 
> If i understand you correct Silivo you seem to say that the midi API simply not have the ability to generate iterative sends that are in sync with clock using the functionality that now within Javascript?
> Or if i missunderstand you, what would you propose to do to get iterative sends in sync with clock?
> 
> Jonas
> 

This is all hypothetical since I do not know the Midi API. But since 
that API is about generating music I would expect it to support some 
form of time axis logic that allows you to play sound sequences at 
specific relative intervals. Having to depend on setTimeout and 
immediate playback to achieve proper timing sounds like a hopeless approach.

[toc] | [prev] | [next] | [standalone]

#39624

torsdag 11 mars 2021 kl. 16:05:09 UTC+1 skrev Silvio:
> On 3/11/21 3:07 PM, Jonas Thörnvall wrote: 
> > 
> > If i understand you correct Silivo you seem to say that the midi API simply not have the ability to generate iterative sends that are in sync with clock using the functionality that now within Javascript? 
> > Or if i missunderstand you, what would you propose to do to get iterative sends in sync with clock? 
> > 
> > Jonas 
> >
> This is all hypothetical since I do not know the Midi API. But since 
> that API is about generating music I would expect it to support some 
> form of time axis logic that allows you to play sound sequences at 
> specific relative intervals. Having to depend on setTimeout and 
> immediate playback to achieve proper timing sounds like a hopeless approach.
Well if you find out let me know.

Thanks Silvio.

[toc] | [prev] | [next] | [standalone]

#39620

torsdag 11 mars 2021 kl. 12:57:41 UTC+1 skrev Arno Welzel:
> Jonas Thörnvall: 
> 
> > I have a question i shift some 12 000 note events. 
> > During 5 min 48 seconds. 
> > 
> > That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> > 
> > Can that really be reasonable? 
> 
> Yes. Because setTimeout() will start a timer at the point when it is 
> called. When the handler then needs 0.0025 seconds to deal with the 
> event before the next setTimeout() call is done this sums up to 30 
> seconds for 12000 events. 
> 
> What you need is setInterval() and clearInterval(): 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval> 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearInterval> 
> 
> 
> This call will cause a function to be called *exactly* every n 
> milliseconds, regardless how long this function will take to handle the 
> call. So also make sure that the function will not take longer than the 
> interval is. 
> 
> Also keep in mind that you do NOT call setInterval() again! You call 
> that only ONCE to start the repeated interval calls and to stop it again 
> you use clearInterval() using the ID which you got from setInterval(). 
> 
> 
> -- 
> Arno Welzel 
> https://arnowelzel.de

It seem that quantization using setInterval really locks up resources? Say that the resolution is 969 parts per quarter note, That will be alot of calls and most of them empty without any event content.
I guess one store it all in a array, where most elements empty?

But having a timed intervall running some 1000-2000 times every second seem like you waste resources, that could be used for rendering or recording?

And then again how is the midi API timings thought to be used they seem superfluos. You can't use them for loops so how do they think people would use it, just as information?
The only thing i could think up was something like this and it made the lag and latency even worse.

function STARTPLAY2(){
	evTiming=copyEv[0];
	if (keepGoing) {
		if (copyEv.length) {
			//console.log(performance.now()-oldPerformance);
			if(performance.now()-oldPerformance>evTiming){
				//alert(performance.now()-oldPerformance+"-----"+evTiming);
				oldPerformance=window.performance.now();
				outportarr[outportindex].send(noteMessage.shift(),window.performance.now() + copyEv.shift());
			}
		}
	setTimeout(STARTPLAY2,0);
	}
}

[toc] | [prev] | [next] | [standalone]

#39622

torsdag 11 mars 2021 kl. 12:57:41 UTC+1 skrev Arno Welzel:
> Jonas Thörnvall: 
> 
> > I have a question i shift some 12 000 note events. 
> > During 5 min 48 seconds. 
> > 
> > That cause ca 30 seconds of lag in the shift sequence of note intervals/timeout lengths. I could understand the delay add up to some 1000 ms, but 30 000????? 
> > 
> > Can that really be reasonable? 
> 
> Yes. Because setTimeout() will start a timer at the point when it is 
> called. When the handler then needs 0.0025 seconds to deal with the 
> event before the next setTimeout() call is done this sums up to 30 
> seconds for 12000 events. 
> 
> What you need is setInterval() and clearInterval(): 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval> 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearInterval> 
> 
> 
> This call will cause a function to be called *exactly* every n 
> milliseconds, regardless how long this function will take to handle the 
> call. So also make sure that the function will not take longer than the 
> interval is. 
> 
> Also keep in mind that you do NOT call setInterval() again! You call 
> that only ONCE to start the repeated interval calls and to stop it again 
> you use clearInterval() using the ID which you got from setInterval(). 
> 
> 
> -- 
> Arno Welzel 
> https://arnowelzel.de
I will make a quantised call routine using setInterval just for comparisson, with setTimout and see how it turn out.  I am not sure i will be able  to render and record while playing up though. Well depending on the PPQ and BPM.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web