Your reply explains perfectly why I couldn't get this to work Randell. My use case is generating DTMF tones via an oscillator and mixing them with the gUM stream (in the absence of an RTCDTMFSender implementation). It works fine on Chrome, but as soon as I tried to add a node between the LocalMediaStream and RTCPeerConnection on FF, audio was dropped.
Is there any estimate as to when the fixes might land? Or as the other poster mentioned, is there any feasible workaround you could suggest? John McLaughlin On Thursday, January 9, 2014 4:21:50 PM UTC, Randell Jesup wrote: > On 1/9/2014 8:29 AM, [email protected] wrote: > > > I am developing a multi peer audio conferencing software (of sorts) and > > since using the Web Audio API handles playback better (faster) than an HTML > > 5 audio element. I would like to use it. Firefox is currently supporting > > Web Audio (AudioContext) and so I am working on migrating my software over > > to playing back both local and remote streams using AudioContext for > > Firefox (because Chrome does not support "createMediaStreamSource" on > > remote streams... yet) > > > > > > Additionally, for those browsers that support WebRTC and Web Audio we give > > them the possibility to use effects (such as distortion and reverb) on > > their stream. Here is where I am running into problems and I can't find > > exactly where the problem lies... so I'm having difficulty in coming up > > with a solution. > > > > > > If a peer using Chrome(31) sends a stream that has effects applied to it > > using Web Audio both Firefox(26-29) and Chrome can playback the stream. If > > a peer is using Firefox and applies effects using Web Audio neither can > > playback the stream. > > > > > > There is no apparent difference in SDP offers/answers. The only real > > difference, that I discovered, is that the Firefox stream taken directly > > from getUserMedia is labeled as [object LocalMediaStream] and if I pass it > > through AudioContext it is then labeled as [object MediaStream]... even > > after using "addStream" to set it as my local stream when setting up the > > peer connection. > > > > To reduce latency and avoid latency buildup in clock rate mismatch cases > > between the internal streams and the microphone input, audio going from > > a getUserMedia MediaStream (LocalMediaStream) to a PeerConnection > > 'bypasses' the MediaStreamGraph itself (PeerConnection uses direct > > notification of data being added to the stream as its source, instead of > > the processed output of the stream). This needs to be fixed for cases > > where the stream added to the PeerConnection isn't a LocalMediaStream, > > though that also means that there's a possibility that microphone > > sources processed with WebAudio will drift (more delay or occasional > > underflows/glitches), which also needs to be resolved with resampling > > (bug 908834 and 818822) > > > > I filed a bug to track this, bug 958090. Note that while it can be > > fixed on it's own, as mentioned it will cause problems when used until > > the resampling bugs are fixed. > > > > -- > > Randell Jesup, Mozilla _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
