Closed Bug 878407 Opened 7 years ago Closed 7 years ago

WebAudio Assertion failure: readPosition >= 0.0 (Why are we reading before the beginning of the buffer?) and crash [@mozilla::dom::DelayNodeEngine::ProduceAudioBlock]

Categories

(Core :: Web Audio, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: posidron, Assigned: ehsan)

References

(Blocks 1 open bug)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

Attached file testcase
On Windows: bp-e22c67da-101d-4542-b0ef-e46712130601.
Crash Signature: [@ mozilla::dom::DelayNodeEngine::ProduceAudioBlock(mozilla::AudioNodeStream*, mozilla::AudioChunk const&, mozilla::AudioChunk*, bool*) ]
OS: Mac OS X → All
Hardware: x86_64 → All
So here we have mMaxDelay set to 0.44679999999999997, which means mMaxDelayTime*48000==21446.399999999998, so the buffer length is set to 21446.  Then later on we have writeIndex == 0, and currentDelayTime == 0.44679999999999997 (the max), so readPosition ends up being -0.39999999999781721.  The bug here is that we use NS_lround to calculate the buffer size, which means that if the fraction value of mMaxDelay*sampleRate is less than 0.5, we end up with 1 fewer item in the buffer than expected.
Attached patch Patch (v1)Splinter Review
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #757045 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/0fc2452f1385
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.
Component: Video/Audio → Web Audio
You need to log in before you can comment on or make changes to this bug.