Hi Marco,
thanks for responding. In AVRCP case, it is better to be handled by an
application, I think. Though I am not sure whether an app could handle
all "audio stop use cases" on FirefoxOS. Could a following use case be
handled by the new attribute/API?
- Stop all audios played in web contents in browser app on FirefoxOS
when user locks screen or user select power down.
IMHO, there should be a way to forcibly stop all audios played in web
contents in browser app. If it is done in gecko, we could force this
policy to all apps on FirefoxOS.
Sotaro
(2012/10/31 0:12), Marco Chen wrote:
Dear Sotaro,
Thanks for the new point provided.
I think if App followed the restrict of callback from new attribute/API,
then there should be ok on this case too.
ex: The Music/Video player on playing will stop itself while phone call
appeared.
Even play command is sent from AVRCP, the music/video player still can't
play due to restrict from callback.
And this is still a good case to show why I suggest music is stopped by App.
In this mechanism, App knows&contols all it's own behavior so it can be adapted
to different use cases.
ex: Imagin that Gecko stopped music directly.
a. music player is on playing.
b. Gecko stop music stream due to phone call.
c. play command is sent by AVRCP.
d. music player call music playing again.
e. From the perspective of UI, there is no any corrsponding UX for this
situation.
Because App didn't know why it can't play in this time or BT headset
didn't receive correct response.
Sincerely yours.
----- Original Message -----
From: "Sotaro Ikeda" <[email protected]>
To: [email protected]
Cc: "Timothy B. Terriberry" <[email protected]>,
[email protected]
Sent: 2012年10月30日 星期二 12:50:58
Subject: Re: [B2G] Policy for Audio Competing is conflict betwen B2G & Desktop
In near future, FirefoxOSv2? might support bluetooth AVRCP profile.(but
I do not know...)
By using AVRCP, a user could control music playback via bluetooth
headset. IMHO, it is better to think about it.
sotaro
(2012/10/30 13:23), Robert O'Callahan wrote:
On Tue, Oct 30, 2012 at 4:43 PM, Timothy B. Terriberry <
[email protected]> wrote:
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).
Right.
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.
Good point.
That's a good argument for just dispatching events and letting the
application take care of stopping and starting playback.
Rob
_______________________________________________
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
