Closed Bug 965483 Opened 11 years ago Closed 11 years ago

Audio stops after a few second with getUserMedia if video:false

Categories

(Core :: Web Audio, defect)

26 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 934512

People

(Reporter: davidj, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36 Steps to reproduce: - call getUserMedia({audio:true,video:false}, Success, Failure); Actual results: After about 5 seconds, audio data is all 0 and the little green camera icon in the url bar disappears (indicating that firefox is not recording any more). Expected results: Shouldn't stop recording after 5 seconds.
You can see the bug here: http://webaudiodemos.appspot.com/pitchdetect/index.html Click on 'live input', then immediately click 'share selected device'. For some reason the bug only occurs if you click 'share selected device' quickly. If you wait a few seconds it seems to work fine.
Here is a workaround for anyone interested: https://support.mozilla.org/en-US/questions/984179
Paul -- This looks to be a Web Audio issue and not a WebRTC issue. Can I ask you to put your spec editor hat on and say if we're doing the right thing here or not? We're clearly not holding a strong reference here, and I think the question is: should we be? It looks like we should be, except I'm not sure if "connected in a cycle" is applicable here or not: https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#lifetime-AudioNode If we aren't doing the right thing per the spec (and/or there's a bug in our implementation), I can find someone else to fix it (unless you prefer to). Thanks.
Component: WebRTC → Web Audio
Flags: needinfo?(paul)
Same issue as bug 934512. Garbage collection should not be observable, so the objects producing sound should not be collected.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
(In reply to Maire Reavy [:mreavy] from comment #3) > Paul -- This looks to be a Web Audio issue and not a WebRTC issue. Can I > ask you to put your spec editor hat on and say if we're doing the right > thing here or not? We're clearly not holding a strong reference here, and I > think the question is: should we be? > > It looks like we should be, except I'm not sure if "connected in a cycle" is > applicable here or not: > https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification. > html#lifetime-AudioNode > > If we aren't doing the right thing per the spec (and/or there's a bug in our > implementation), I can find someone else to fix it (unless you prefer to). > Thanks. Yes, as Karl says, this is a bug, and is already tracked.
Flags: needinfo?(paul)
You need to log in before you can comment on or make changes to this bug.