Closed
Bug 878407
Opened 11 years ago
Closed 11 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)
Core
Web Audio
Tracking
()
RESOLVED
FIXED
mozilla24
People
(Reporter: posidron, Assigned: ehsan.akhgari)
References
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(2 files)
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
|
Reporter | |
Comment 1•11 years ago
|
||
|
||
Comment 2•11 years ago
|
||
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
|
Assignee | |
Comment 3•11 years ago
|
||
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.
|
|
Assignee | |
Comment 4•11 years ago
|
||
Attachment #757045 -
Flags: review?(roc) → review+
|
|
Assignee | |
Comment 5•11 years ago
|
||
|
||
Comment 6•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
|
|
Assignee | |
Comment 7•11 years ago
|
||
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.
Description
•