Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do detect optical cable(S/PDIF) using exoplayer? #7617

Closed
PratimMallick opened this issue Jul 10, 2020 · 16 comments
Closed

How do detect optical cable(S/PDIF) using exoplayer? #7617

PratimMallick opened this issue Jul 10, 2020 · 16 comments
Assignees
Labels

Comments

@PratimMallick
Copy link

To determine whether to serve dolby or stereo content, out app needs to determine whether the device(androidTv or android box) is connected to a surround sound system or not.
This is possible when the sound system connects to the device via HDMI ARC by reading the AudioCapabilities. But this does not help when the sound system is connected via optical cable or S/PDIF. How do we detect if the output supports surround sound (Dolby or DTS) when connected via optical cable

@tonihei
Copy link
Collaborator

tonihei commented Jul 13, 2020

@andrewlewis Do you know if there is way to detect that? Our DefaultTrackSelector doesn't take this into account at the moment, so if there were a reliable way to detect number of available output channels, we should also make this part of the default track selection (similar to how we automatically limit video resolution to the screen size).

@andrewlewis
Copy link
Collaborator

Last time I tested this I found that the HDMI audio plug intent was updated for optical connection too (that was on a Sony TV, I think). Which device are you using?

If that intent doesn't help, you could try using registering an audio device callback (from API 23). #1993 is somewhat related and could be broadened to track listening for audio device changes both via the HDMI intent and the audio device callback (depending on API version) as well as allowing selection.

@PratimMallick
Copy link
Author

I am testing this on TCL android tv (Os 9).

@andrewlewis
Copy link
Collaborator

@PratimMallick Please first check that the HDMI audio plug intent (which we already have a helper for) doesn't expose the required information, and, if not, give the audio device callback approach mentioned in my previous comment a try. You can build an AudioCapabilities instance yourself based on the audio device information and re-create the player as needed when it changes. Please reply here to let us know whether that API works for your device.

@tonihei Regarding track selection based on channel count, the audio renderer supportsFormat check does take into account what output is possible based on the AudioCapabilities but is the proposal to prefer tracks with higher channel count? If so I suggest we track that in a separate bug.

@tonihei
Copy link
Collaborator

tonihei commented Jul 13, 2020

If the track selection is covered by the supportsFormat check then there is nothing we need to do in that regard I think.

@PratimMallick
Copy link
Author

@andrewlewis The HDMI audio plug intent does not give the required information in this TV when optical cable is connected. It gives correct info when HDMI ARC is connected to the Tv. Will check the second option you mentioned

@PratimMallick
Copy link
Author

@andrewlewis The AudioDeviceCallback also doesnot give a callback when a optical cable is connected or disconnected.

The issue here is while playing EAC3 encoded stream on Android TV when optical cable is connected, the supportsOutput method of DefaultAudioSink returns false and thus allowPassthrough returns false for the mimeType audio/eac3 whereas passthrough is possible in optical cable.

How to solve this issue for AndroidTVs?

@andrewlewis
Copy link
Collaborator

The AudioDeviceCallback also doesnot give a callback when a optical cable is connected or disconnected.

Hm, that's quite surprising. Are you certain the callback is set up correctly? I guess a good way to check is to try plugging in HDMI and checking that notifies the callback.

If you call getAudioCapabilities repeatedly (say every second) and then plug/unplug the optical cable, do the capabilities change at all?

@PratimMallick
Copy link
Author

PratimMallick commented Jul 16, 2020

@andrewlewis I re-checked with HDMI ARC connected. This Callback gives correct result, that is TYPE_HDMI_ARC with the correct encoding type. But when Optical cable is connected, this returns only TYPE_BUILT_IN_SPEAKER whereas it should return TYPE_LINE_DIGITAL. I think there is some issue in detecting spdif cable in android.

@andrewlewis
Copy link
Collaborator

I've asked the audio framework team for guidance and will update here when they reply [Internal ref: b/161525145].

@PratimMallick
Copy link
Author

PratimMallick commented Jul 17, 2020

Thanks @andrewlewis . Will wait for an update here.

In the meantime, I have figured out that reading the Global setting key nrdp_external_surround_sound_enabled gives the correct information if passthrough is allowed or not based on the user selection in Digital output setting of Sound.So indirectly we get to know that there is a way for exoplayer to allow passthrough. So the AudioCapabilities class can read this value as well along with ACTION_HDMI_AUDIO_PLUG intent values.

@andrewlewis
Copy link
Collaborator

The audio framework team indicated that providing an API to detect this is not feasible in general, as there is no kernel event for S/PDIF device connection and not all devices have physical detection for whether it's plugged in.

Regarding nrdp_external_surround_sound_enabled, does that work reliably on this device and get updated on plug/unplug? If so, please could you give us the full build fingerprint output by adb shell getprop ro.build.fingerprint and we can consider adding a special case for this device.

@andrewlewis
Copy link
Collaborator

Update: rereading your previous comment it sounds like nrdp_external_surround_sound_enabled is actually just reflecting the user setting of whether encoded output is enabled. Could you check whether the AudioDeviceInfo encodings or HDMI audio intent reflect the same information? If so, using those standard APIs is preferable to relying on a non-standard global setting to detect this.

@PratimMallick
Copy link
Author

Yes that's right @andrewlewis. nrdp_external_surround_sound_enabled just reflects the user setting of whether pass-through(either by HDMI_ARC or Optical Cable) is enabled or not.

Neither AudioDeviceInfo nor 'HDMI Audio intent' does not reflect this when Optical Cable is connected. That is why I am searching via global settings.

FYI:
NRDP here stands Netflix Ready Device Platform, which is a sdk that is installed on devices which supports netflix and this sdk sets the value of nrdp_external_surround_sound_enabled to 1 or 0 depending on if user has enabled pass-through on the device or not(irrespective of being connected via optical cable or HDMI ARC)

@PratimMallick
Copy link
Author

Is there any other way of knowing if passthrough is enabled by the user or not? Is there any other standard global key that can be checked at app level?

@andrewlewis
Copy link
Collaborator

Is there any other way of knowing if passthrough is enabled by the user or not? Is there any other standard global key that can be checked at app level?

There is the global setting external_surround_sound_enabled which we currently check in AudioCapabilities. The should at least cover certain devices where an option is available to the user.

As/when other new APIs are available for querying this we can use them but I don't think there's anything actionable left on our side for this so I will close the issue.

@google google locked and limited conversation to collaborators Nov 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants