[webkit-reviews] review requested: [Bug 105518] "PlaybackTime" parameter is not present in AudioProcessingEvent Interface as per W3C spec : [Attachment 193241] WIP

[bugzilla-daemon at webkit.org]

Praveen Jadhav <praveen.j at samsung.com> has asked  for review:
Bug 105518: "PlaybackTime" parameter is not present in AudioProcessingEvent
Interface as per W3C spec
https://bugs.webkit.org/show_bug.cgi?id=105518

Attachment 193241: WIP
https://bugs.webkit.org/attachment.cgi?id=193241&action=review

------- Additional Comments from Praveen Jadhav <praveen.j at samsung.com>
Good thing to have pointed out "inputArrayL.duration" not defined. I did some
more trials with the test case and have updated the comments.

I couldn't verify the test with OfflineAudioContext because of audio rendering
and hence continued with normal AudioContext. However, I have made provision to
cyclically increase bufferSize of scriptProcessorNode with each test. i.e.,
scriptProcessorNode will be created with bufferSize of 256, 512, 1024,...,
16384, 256, 512..etc so that we can verify for all bufferSize values.

Glitch happens with this test at lower bufferSize(256 and 512) values and as
the size increases, there is not noticable glitch problem. Also, In the current
testcase, audio glitch is noticable when switching from first callback to
second in all cases since outputBuffer will be filled with 0s before that.

I have replaced noteOn() with start() but not using stop() as I need a callback
function to reset onaudioprocess to null at the end of 'duration'(else, audio
continues to play data generated by Math.sin() function).

I have included a layout test case to validate attributes of
AudioProcessingEvent as well. In this case, I am using createScriptProcessor()
instead of createJavaScriptNode() to correct Timeout error observed in earlier
patches. Not sure if we can include the changes implemented in manual test case
to layout test as this shouldn't be automated.


Finally, about the logic, m_playbackTime variable is introduced and its value
is set before calling callOnMainThread()(to avoid glitch issue between
buffers). The output of the overlapping SINE waves is not exactly silent
always, but varies with each test from 0 to 2 radians(~116 degrees) for 100Hz
frequency and outputBuffer always lagged behind inputBuffer. This works out be
to a delay of upto 3ms than the calculated value in m_playbackTime. I tried
with below logic to account for the delay:

	   m_playbackTime = context()->currentTime() + outputBuffer->duration()
- (framesToProcess / context()->sampleRate());

but the phase variation changed for each test. Any inputs for this?