Bug 77225

Summary: noteGrainOn needs more tests
Product: WebKit Reporter: Raymond Toy <rtoy>
Component: Web AudioAssignee: Raymond Toy <rtoy>
Status: RESOLVED FIXED    
Severity: Normal CC: crogers, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 76659    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Raymond Toy
Reported 2012-01-27 08:54:52 PST
Bug 76659 adds a timing test for noteGrainOn, but only tests the case where the offset is 0 and the duration is fixed. That test also does not test that the output is correct, except for the position of the signal. Additional tests need to be written to cover the case where the offset and duration change. We also need to test whether the correct part of the signal is produced.
Attachments
Patch (20.73 KB, patch)
2012-01-30 13:35 PST, Raymond Toy
no flags
Patch (22.26 KB, patch)
2012-01-30 14:05 PST, Raymond Toy
no flags
Patch (23.10 KB, patch)
2012-01-31 15:55 PST, Raymond Toy
no flags
Patch (23.22 KB, patch)
2012-02-01 10:12 PST, Raymond Toy
no flags
Raymond Toy
Comment 1 2012-01-30 13:35:49 PST
Raymond Toy
Comment 2 2012-01-30 14:05:59 PST
Raymond Toy
Comment 3 2012-01-30 14:06:34 PST
Forgot to add expected results for the new test to the patch.
Chris Rogers
Comment 4 2012-01-31 14:08:49 PST
Comment on attachment 124597 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124597&action=review Great test! I have a few nit comments: > LayoutTests/webaudio/note-grain-on-play.html:14 > + description("Test noteGrainOn."); Can we have a *slightly* more detailed description of the test here -- could even be as simple as: "Test noteGrainOn offset rendering." > LayoutTests/webaudio/note-grain-on-play.html:17 > + // Various sections of the ramp are played out at different "played out" -> "rendered with noteGrainOn()" > LayoutTests/webaudio/note-grain-on-play.html:25 > + var trueGrainOffset = []; can we call this either "trueGrainOffsetTime" or "grainOffsetTime" > LayoutTests/webaudio/note-grain-on-play.html:30 > + var rampOffset = timeToSampleFrame(trueGrainOffset[rampNumber], sampleRate); "rampOffset" -> "rampOffsetFrame" > LayoutTests/webaudio/note-grain-on-play.html:31 > + var rampLength = endFrame - startFrame; rampLength -> rampFrameLength > LayoutTests/webaudio/note-grain-on-play.html:72 > + // section of our ramp signal. It seems like this comment really belongs just inside the loop, but we want a comment here describing that we're looping through each of the rendered grains, one at a time... > LayoutTests/webaudio/note-grain-on-play.html:76 > + testFailed("Ramp " + k + " incorrect. Expected " + result.expected + " but received " + result.actual + " at sample frame " + result.frame); I'm wondering if "Grain" might be a better word than "Ramp", since I think of the "ramp" as being the entire "linearRampBuffer", while the "grain" is a single rendering of a portion of the ramp. It's true that a sub-section of the ramp is itself a ramp, but that doesn't seem helpful in trying to distinguish the concepts. So: "verifyRamp" -> "verifyGrain", and other uses of word ramp... > LayoutTests/webaudio/note-grain-on-play.html:108 > + linearRampBuffer = createSignalBuffer(context, function (k) { return k + 1; }); nit: no space after function -- should be "function(k)" Also, please add comment explaining that we use "k + 1" instead of "k" so that the ramp starts at a non-zero value.
Raymond Toy
Comment 5 2012-01-31 15:55:27 PST
Raymond Toy
Comment 6 2012-01-31 15:59:39 PST
Comment on attachment 124597 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124597&action=review >> LayoutTests/webaudio/note-grain-on-play.html:14 >> + description("Test noteGrainOn."); > > Can we have a *slightly* more detailed description of the test here -- could even be as simple as: > > "Test noteGrainOn offset rendering." Oops. Better description added. >> LayoutTests/webaudio/note-grain-on-play.html:17 >> + // Various sections of the ramp are played out at different > > "played out" -> "rendered with noteGrainOn()" Done. >> LayoutTests/webaudio/note-grain-on-play.html:25 >> + var trueGrainOffset = []; > > can we call this either "trueGrainOffsetTime" or "grainOffsetTime" Done. >> LayoutTests/webaudio/note-grain-on-play.html:30 >> + var rampOffset = timeToSampleFrame(trueGrainOffset[rampNumber], sampleRate); > > "rampOffset" -> "rampOffsetFrame" Done. >> LayoutTests/webaudio/note-grain-on-play.html:31 >> + var rampLength = endFrame - startFrame; > > rampLength -> rampFrameLength Done. I've also made similar changes in other places to make it clear if we're doing time or frames. >> LayoutTests/webaudio/note-grain-on-play.html:72 >> + // section of our ramp signal. > > It seems like this comment really belongs just inside the loop, but we want a comment here describing that we're looping through each of the rendered grains, one at a time... Done. >> LayoutTests/webaudio/note-grain-on-play.html:76 >> + testFailed("Ramp " + k + " incorrect. Expected " + result.expected + " but received " + result.actual + " at sample frame " + result.frame); > > I'm wondering if "Grain" might be a better word than "Ramp", since I think of the "ramp" as being the entire "linearRampBuffer", while the "grain" is a single rendering of a portion of the ramp. It's true that a sub-section of the ramp is itself a ramp, but that doesn't seem helpful in trying to distinguish the concepts. > > So: "verifyRamp" -> "verifyGrain", and other uses of word ramp... Yes, I agree. I think I've made this change everywhere. >> LayoutTests/webaudio/note-grain-on-play.html:108 >> + linearRampBuffer = createSignalBuffer(context, function (k) { return k + 1; }); > > nit: no space after function -- should be "function(k)" > > Also, please add comment explaining that we use "k + 1" instead of "k" so that the ramp starts at a non-zero value. Done.
Chris Rogers
Comment 7 2012-01-31 17:25:14 PST
Comment on attachment 124838 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124838&action=review > LayoutTests/webaudio/note-grain-on-play-expected.txt:7 > +PASS All 100 pulses ended at the correct time. Lines 5:7 use the word "pulse" but line 8 uses "grain" -- it seems like "grain" should be used everywhere since it's no longer a square pulse > LayoutTests/webaudio/note-grain-on-play.html:18 > + // out at different times, and we verify that the actual output nit: can remove the word "out" > LayoutTests/webaudio/note-grain-on-play.html:19 > + // matches our expectations. "verify that the actual output matches our expectations" is pretty generic and vague. It could be used to describe any test. Can we have a sentence that's much more explicit? > LayoutTests/webaudio/note-grain-on-play.html:29 > + function verifyGrain(renderedData, startFrame, endFrame, rampNumber) { rampNumber -> grainIndex (or grainNumber) > LayoutTests/webaudio/note-grain-on-play.html:30 > + var rampOffsetFrame = timeToSampleFrame(grainOffsetTime[rampNumber], sampleRate); rampOffsetFrame -> grainOffsetFrame > LayoutTests/webaudio/note-grain-on-play.html:31 > + var rampFrameLength = endFrame - startFrame; rampFrameLength -> grainFrameLength > LayoutTests/webaudio/note-grain-on-play.html:64 > + var startEndFrames = findStartAndEndSamples(renderedData); naming nit: findStartAndEndSamples -> findStartEndFrames (down below you have a function called "verifyStartEndFrames" without an "And") either both should have "And" or neither
Raymond Toy
Comment 8 2012-02-01 10:12:50 PST
Raymond Toy
Comment 9 2012-02-01 10:13:52 PST
I think I've addressed all of the review comments and updated accordingly.
Chris Rogers
Comment 10 2012-02-02 12:11:55 PST
Looks good.
Kenneth Russell
Comment 11 2012-02-02 17:51:52 PST
Comment on attachment 124963 [details] Patch rs=me
WebKit Review Bot
Comment 12 2012-02-02 18:41:05 PST
Comment on attachment 124963 [details] Patch Clearing flags on attachment: 124963 Committed r106612: <http://trac.webkit.org/changeset/106612>
WebKit Review Bot
Comment 13 2012-02-02 18:41:10 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.