Dear Timothy,
Thanks for you to join this discussion.
> This is what happens if you mute the audio output, instead of stopping
> it. I think Rob was suggesting actually stopping it (which would
> appear no different to the app than if the user clicked pause).
Yeah, we are discussing on the case of stopping it from Gecko not just mute.
And imagine that Gecko stopped the music stream but App didn't know this
situation.
Or App didn't process the notification from Gecko about stopping music.
Then user will see App show it's state is on playing not paused.
> but I think we should at
> least consider the WebRTC case, as we may want something we can re-use
> for both cases, rather than multiple non-generic mechanisms.
Thanks for your suggestion about generic mechanism.
Since there are different behaviors on audio competing or mixing,
I just suggest that let App choose it's expected behavior.
Ex: WebRTC App can choose that it didn't want to join "playone" policy,
so we can keep it on the backgroud and mixing with others.
And music player want to join "playone" policy so it will be stopped.
For our own pre-installed App we can ask them to follow our policy.
For app from marketplace, user can choose to remove it according the bug.
Sincerely yours.
----- Original Message -----
From: "Timothy B. Terriberry" <[email protected]>
To: [email protected]
Sent: Tuesday, October 30, 2012 11:43:26 AM
Subject: Re: [B2G] Policy for Audio Competing is conflict betwen B2G & Desktop
For the record, see https://bugzilla.mozilla.org/show_bug.cgi?id=709883
Marco Chen <[email protected]> wrote:
> Dear Rob,
>
> For method 1:
> [...]
> Result: After phone call, user will find the time is already
> shifted later or even the music is jumped to another one.
This is what happens if you mute the audio output, instead of stopping
it. I think Rob was suggesting actually stopping it (which would
appear no different to the app than if the user clicked pause).
As for a "playOne" attribute, or whatever you want to call it, part of
the problem for WebRTC at least is that there may be multiple media
elements involved in a single call (especially a multi-party video
call). That may not matter for the B2G case, but I think we should at
least consider the WebRTC case, as we may want something we can re-use
for both cases, rather than multiple non-generic mechanisms.
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
