https://mxr.mozilla.org/mozilla-central/source/content/media/MediaStreamGraph.cpp#2781 This code is very buggy because it creates a gGraph the first time using the 2 parameters (aHint and the audiochannel). But the second time it runs, it ignores the parameters and returns the previous gGraph object. That has to be fixed and here the proposal: 1. GetInstance() should not take parameters. Instead "Normal" audio channel must be used and no hint should be taken. 2. MediaStream should store the audiochannel. 3. the audio backend should be created lazily when it's needed: it means when MediaStream has something to do. 4. At this point we create the cubeb backend if we don't already have it something for that particular channel. 5. If the MediaStream changes AudioChannel, we can try to change the cubeb backend. Feedbacks?

An MSG instance is driven by a libcubeb callback. So there can only be one cubeb instance per MSG. This means we have to have one MSG per AudioChannel. That means you can't connect a MediaStream to two different AudioChannel outputs, but I hope we can live with that at least for now. (It's fixable later, at the cost of introducing some latency for such MediaStreams.) That means we need to change gGraph into a collection indexed by AudioChannel.

The problem I see is this: AudioContext() creates an AudioDestinationNode() and that get an instance of a MediaStreamGraph object using a particular AudioChannel. In AudioContext() we can change the AudioChannel using 'setMozAudioChannelType(foobar)'. That doesn't really touch the MediaStreamGraph backend but it just changes an attribute in MediaStream. Can we connect a MediaStream to a different backend when the AudioChannel changes?

(In reply to Andrea Marchesini (:baku) from comment #2) > The problem I see is this: AudioContext() creates an AudioDestinationNode() > and that get an instance of a MediaStreamGraph object using a particular > AudioChannel. > > In AudioContext() we can change the AudioChannel using > 'setMozAudioChannelType(foobar)'. That doesn't really touch the > MediaStreamGraph backend but it just changes an attribute in MediaStream. > > Can we connect a MediaStream to a different backend when the AudioChannel > changes? No. Can we take away the ability to change the audio channel type?

It means we have to remove SetMozAudioChannelType. But yes. we can.

(In reply to Andrea Marchesini (:baku) from comment #4) > It means we have to remove SetMozAudioChannelType. But yes. we can. Let's do that!

If we like this patch, we have to inform the gaia team about this readonly mozAudioChannelType attribute because I guess they are using it a lot for ffos.

https://tbpl.mozilla.org/?tree=Try&rev=87a58f9715fc Waiting for a full green result on try, I write an email to gaia-dev mailing list.

Backed out under the strong suspicion of causing bug 1075345, which is extremely frequent on OSX. https://hg.mozilla.org/integration/mozilla-inbound/rev/8a3de2f8ec3d

(In reply to Andrea Marchesini (:baku) from comment #6) > Created attachment 8496783 [details] [diff] [review] > bug.patch > > If we like this patch, we have to inform the gaia team about this readonly > mozAudioChannelType attribute because I guess they are using it a lot for > ffos. This broke a lot of stuff in gaia, can we communicate changes like this before this happens again in the future? We would also need some time to adopt our code and land at the same time that gecko does if it's a breaking change like this.

It seems that this patch breaks some mochitest on OSX (bug 1075345). Wondering if you have some idea why... Of course, I cannot reproduce this issue locally (on linux).

Also caused a big spike on Android (bug 1061675).

(In reply to Andrea Marchesini (:baku) from comment #13) > It seems that this patch breaks some mochitest on OSX (bug 1075345). > Wondering if you have some idea why... Of course, I cannot reproduce this > issue locally (on linux). I don't know. Also, I'm on vacation. I suggest you add some info()s to the test and to try pushes on Mac to figure out at which point during the test we get stuck.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=5a8651f9a26e If green, we can land it.

https://hg.mozilla.org/integration/mozilla-inbound/rev/5a476e673470 Will be watching carefully for any orange spikes.

Intermittents are back (see deps). Backed out. On the bright side, no reports of any Gaia issues this time around. https://hg.mozilla.org/integration/mozilla-inbound/rev/dccf8c0eb2b7

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e14cdddbcf5f it seems that the dep issue is a timeout problem. Increasing the timeout looks fully green so far.

Hi, seems the patch didn't apply cleanly: unable to find 'content/media/MediaStreamGraph.cpp' for patching 6 out of 6 hunks FAILED -- saving rejects to file content/media/MediaStreamGraph.cpp.rej unable to find 'content/media/MediaStreamGraphImpl.h' for patching 2 out of 2 hunks FAILED -- saving rejects to file content/media/MediaStreamGraphImpl.h.rej unable to find 'content/media/webaudio/AudioContext.cpp' for patching 1 out of 1 hunks FAILED -- saving rejects to file content/media/webaudio/AudioContext.cpp.rej unable to find 'content/media/webaudio/AudioContext.h' for patching 1 out of 1 hunks FAILED -- saving rejects to file content/media/webaudio/AudioContext.h.rej unable to find 'content/media/webaudio/test/test_mozaudiochannel.html' for patching 2 out of 2 hunks FAILED -- saving rejects to file content/media/webaudio/test/test_mozaudiochannel.html.rej patch failed, unable to continue (try -v)