AudioBufferSourceNode.start treats the 'when' parameter as relative to source creation time

RESOLVED DUPLICATE of bug 943461

Status

()

defect
P2
normal
RESOLVED DUPLICATE of bug 943461
5 years ago
5 years ago

People

(Reporter: cwiiis, Assigned: rfw)

Tracking

Trunk
mozilla29
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

5 years ago
When calling start on an AudioBufferSourceNode with the context's currentTime, it seems that this parameter is treated as relative and it will start currentTime seconds in the future.

This contradicts the specification[1], which says that the 'when' parameter is in the same coordinate system as currentTime, and that any time less than currentTime indicates immediate start, which strongly infers that calling start with currentTime is equivalent to calling start with 0.

In my testing, calling start with the context's currentTime causes the sound to play approximately currentTime seconds in the future.

[1] https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#methodsandparams-AudioBufferSourceNode

I haven't quite figured out how 'stop' interprets its 'when' parameter, but I've not managed to get it to behave in any consistent way :(
Posted file testcase that works as expected (obsolete) —
This plays as expected for me, with pulseaudio.

Does each button start a tone more or less immediately on your system?
Reporter

Comment 2

5 years ago
(In reply to Karl Tomlinson (:karlt) from comment #1)
> Created attachment 8355965 [details]
> testcase
> 
> This plays as expected for me, with pulseaudio.
> 
> Does each button start a tone more or less immediately on your system?

This is odd, your example works, but my code does not. My code works correctly in Chrome. Perhaps because my buffers are created from oggs?

I'll see if I can make a small test-case.
Reporter

Comment 3

5 years ago
Also worth noting, I'm using looping audio when I experience this problem, that also may affect results.
Reporter

Comment 4

5 years ago
(In reply to Chris Lord [:cwiiis] from comment #3)
> Also worth noting, I'm using looping audio when I experience this problem,
> that also may affect results.

disregard this, I see you are in your code too.
Reporter

Comment 5

5 years ago
This is attachment #8355965 [details], modified slightly to better represent how I'm using web audio, that exhibits the error I mention.
Reporter

Comment 6

5 years ago
It seems the issue is that the source's treatment of currentTime is frozen to its creation time? Chrome behaves correctly in this situation.
Reporter

Comment 7

5 years ago
Changing bug title to better describe the bug.
Summary: AudioBufferSourceNode.start treats the 'when' parameter as relative → AudioBufferSourceNode.start treats the 'when' parameter as relative to source creation time
Attachment #8355965 - Attachment description: testcase → testcase that works as expected
Attachment #8355965 - Attachment is obsolete: true
It's as if (time_of_start_call - time_of_node_creation) is added to the |when| parameters.
OS: Windows 8.1 → All
Reporter

Comment 9

5 years ago
Another note, even employing the work-around of not creating the source until it's needed, I'm getting odd treatments of 'when' on Android Nightly (but working fine in Android release).

I've yet to pinpoint what this issue is, but if it's sufficiently different, I'll file a new bug for it.
Reporter

Comment 11

5 years ago
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> Is this WebKit bug relevant here?
> https://bugs.webkit.org/show_bug.cgi?id=114923

No, I don't think so.
Karl -- This sounds like a high P2 to me, but if you and/or Paul think this is an important use case (especially for games), please re-prioritize higher.  Thanks.
Assignee: nobody → karlt
Priority: -- → P2
Duplicate of this bug: 966585
Fixed in https://hg.mozilla.org/mozilla-central/rev/0279107b81d3
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → mozilla29
Duplicate of bug: 943461
Flags: in-testsuite?
Assignee

Comment 15

5 years ago
Posted file test_bug956489.html
Here is a Mochitest test case that tests for this bug.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ac235837f6a
Assignee: karlt → tony
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.