Generator functions can run backwards when called in high frequency
Reported by
matthias...@gmail.com,
May 3 2016
|
||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Steps to reproduce the problem:
1. Make a generator function that will produce a sine wave
2. Create a script processor from a audio context
3. Connect it up and listen
What is the expected behavior?
The generator function would produce a perfect sine wave.
What went wrong?
Every so often you will hear a click.
Did this work before? No
Chrome version: 48.0.2564.116 Channel: stable
OS Version: Kubuntu 16.04
Flash Version: Shockwave Flash 21.0 r0
function* gen(sqlen){i=1;x=0;y=0;z=0.5;while (true){me=true;if (me){;x++;yield(Math.sin(i=i+1/sqlen));me=false;go=true;continue}else{};if (go){;yield(Math.sin(y=y+1/sqlen));me=true;go=false;continue}else{};if(x==y){x;y;}}};generatorr=gen(16);generatorl=gen(16) -- Current generator function
sqtst=ac.createScriptProcessor(16384,0,2);sqtst.onaudioprocess=function(audioProcessingEvent) {
var outputBuffer = audioProcessingEvent.outputBuffer;
var outputData = outputBuffer.getChannelData(0);
for (var sample = 0; sample < outputData.length; sample=sample) {
// add noise to each output sample
outputData[sample++] = generatorl.next().value
}
outputData = outputBuffer.getChannelData(1)
for (var sample = 0; sample < outputData.length; sample=sample) {
// add noise to each output sample
outputData[sample++] = generatorr.next().value
}
};sqtst.connect(ac.destination)
-- Current script processor, ac = new AudioContext
,
May 4 2016
I think, buffers can write a bit too far, the current buffer ends up running into the previous buffer, the buffers get played in order, but there are a few extra samples in each side of the buffer, so you get overlap every time a new buffer is played
,
May 4 2016
I think this is just a plain buffer underrun. If you want us to try your example, you might want to strip out irrelevant parts. ScriptProcessor uses the main thread to fill the buffer. If it misses its given timeframe, you'll hear glitches. What are you trying to achieve here?
,
May 4 2016
I just wanted to produce a sine wave with a scriptprocessor, and no i am sure it is not a buffer under run, I can even keep the buffer almost full even if i go over the buffer 4* on each channel! that is computing a sine wave eight TIMES!! You can make any wave form too, that could be useful...
,
May 4 2016
I tried this out on my Linux machine (fairly powerful) with Chrome beta. No glitching of the audio. Are you running on a lower powered machine?
,
May 4 2016
Ok , il'l have to try it on chrome beta
,
May 5 2016
I checked out the javascript process in gdb, it is using 2 threads, and my computer is too slow for that, i can make triangle waves without trouble... So, yes my computer is too slow, i think this is still a bug, what ever you think As i tried, i could calculate a sine wave 8* and that was the limit where it would slowly drain the buffer, this is a interthread buffer under run
,
May 5 2016
On rare ocassion, chrome unstable can get a buffer stuck in a loop, the same sound is playing over and over again!!
,
May 5 2016
So where is the buffer under run bug??
,
May 5 2016
I don't think there's anything webaudio can do if your javascript code is too slow to return data in time for the audio thread. However, you can make your javascript code faster. Instead of calling Math.sin a zillion times, create a table of sine values and use table lookup (with interpolation if needed) to compute your sine wave. Math.sin is relatively slow. And if this is something other than a test of scriptprocessor nodes, you probably want to use an Oscillator node.
,
May 5 2016
It is user error, i have changed my code, it works now!
,
May 5 2016
Thanks for letting us now. Out of curiosity, what was the error? Something caused too much computation? (I did not examine your code closely to see what it was doing.)
,
May 5 2016
The counter was getting reset every call, once i simplified it, other than that, probably my computer was not powerful enough, chrome was using 65-90% of one core... I also used a copytochannel(), instead of running the loop again.
,
May 6 2016
Probably somthing to do with inefficiency in generator functions, and cache faults in the cpu... My cpu just ended up being too slow for generator functions... It was too much computation, but the cpu could have handled it if there was no latency when accessing memory.
,
May 6 2016
Thanks for the info. Closing (Wontfix: wai) |
||
►
Sign in to add a comment |
||
Comment 1 by cbiesin...@chromium.org
, May 3 2016