Define behavior of the mute button and volume slider when playing media remotely |
|||||
Issue descriptionThis is a feature request and a follow up to the internal bug 21870326. I propose the following behavior: 1. When casting starts, the user visible controls should sync to the remote state. 2. While casting, the controls should control the remote state only and follow the separate mute/volume behavior (muted doesn't set the volume to 0, so unmuting keeps the volume at the previous level). Volume up should probably unmute and volume down shouldn't (but I think it's up to the Cast device to do that). 3. When casting stops, we should sync the volume to the previous setting (so we should keep it at pt 1) -- similar to how device volume keeps different values for different output sinks like when I plug/unplug my headphones. That'd mean that while playing remotely the hardware/keyboard volume commands would affect the visible media element's volume though which IIRC they don't during the local playback. Making those work is tricky though if the user is playing multiple elements - should the volume for all be affected? While at it, I'd also argue that we probably shouldn't handle headset commands when casting anything but it's probably for a separate bug. +Mark, Yuri for desktop inspired thoughts :)
,
Apr 13 2017
+1 I think this makes sense.
,
Apr 17 2017
In general for Cast, volume and mute controls affect device level volume (not stream level volume), for Cast receivers that allow incremental volume control. I do believe volume and mute are kept independent. I believe the Cast SDK provides a separate volume control on Android that implements these semantics for native apps - can it be used in this scenario?
,
Oct 18 2017
Assigning all my bugs to Mounir for him to triage and close/reassign later.
,
Oct 23 2017
Assigning to Mounir for decision so that these get out of the general untriaged bucket.
,
Nov 1 2017
Assigning to zqzhang@ as it's Clank Cast integration.
,
Aug 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by m...@chromium.org
, Apr 12 2017