I side loaded the new Android TV Beta because I has hoping that the new optical settings would fix the issues with my Sonos soundbar only supporting ac3.
I thought initially it was working (last night, I swore it was transcoding the DTS), but I’ve just tried playing a DTS encoded film again and when it plays I get a stereo output, the server is not transcoding the DTS to AC3. I mean this is an improvement over silence, but I’m expecting the server to transcode the unsupported surround track to a supported format (AC3).
I’ve attached logs for the server and also the player.
Any ideas? Player is definitely set to Optical passthrough in the new settings and AC3 is the only codec ticked.
The new preference controls whether or not we allow AC3 and DTS to be played via passthrough. It doesn’t control whether or not we allow ourselves to locally decode the audio. So in scenarios where you only support AC3 via Passthrough, DTS will still be Direct Played and be locally decoded to 2.0 PCM. The two further changes that are under consideration would be:
When we detect only AC3 is available via Passthrough, decode DTS but re-encode to AC3 locally.
Disable Direct Play completely of DTS content when the user has enabled Optical Passthrough.
The latter would solve your issue, but also potentially damages other user scenarios who don’t want their content to be transcoded. Hence why we’re still considering the best improvements here.
I’ll keep my eyes open for any further updates on this, while this is 100% better than it was in that I can guarantee audio, I’m still in the same situation that if I want surround sound then there has to be an AC3 track.
From my point of view the first option you presented solves it, if the client doesn’t support DTS through optical then let the server transcode it, this also applies to other formats True HD, EAC3 etc, if on optical passthrough then as far as I see the only formats it should direct play are those that are selected in the optical passthrough settings, everything else should get downmixed/transcoded to AC3.
To me solution no. 1 sounds the best, local decode and re-encode. A server transcode wouldn’t hurt except there is this long-standing issue where if you have subtitles and need to transcode the audio causes a full video/audio transcode on the Android TV platform, and that IS unacceptable.
But yes, we are now close to having something that will work correctly with the Sonos playbar, given that Sonos is a “partner” of Plex, you’d think that they’d want to make sure that there’s a good experience with the Sonos kit, despite this being movie related and not sound.
At least I don’t have to explain why there’s no sound now, the conversation has just changed to why there’s no surround sound! lol
I guess my question right off the bat is why isn’t Plex choosing a codec for conversion that will support the multi-channel speaker count (ie 5+1) instead of defaulting to 2+0? Stereo (2+0) should always be the last resort.
Your question is excellent and goes beyond the new setting as I have observed that when it decides to transcode EAC3 (my equipement only supports AC3 and DTS) it transcodes it to 2ch AAC. It does NOT do that when I use my Roku, there EAC3 gets transcoded to AC3 as it should.
Heck, I’d even accept a “Only support AC3” temporary fix setting (that tells the client to tell the server to only send AC3) until they sort out the best method of solving this, would solve the issue for anybody with a Sonos system.
This issue has been here for a long time and has only just seen some action after I tagged elan in a different thread where he was interacting with customers.
Thinking about it, the temporary solution would be to add an extra option to the passthrough settings, “Sonos Playbar” (In addition to the current Disabled/HDMI/Optical options) that sets it so that the server transcodes to AC3, surely this would be an easy and quick option to implement? I know this still opens up the transcoding bug with subtitles, but would suffice for most of the time.
@fizzyade - I’ve submitted some changes to the app which will force transcode all unsupported multichannel audio to something supported, if Optical Passthrough is disabled. As I mentioned above, it’s not the ideal fix but we hope it will be enough until we get time to do it properly.
The change is being considered for v7.11 and will go under the normal review and test processes. Hopefully it will land in time to make the cut, but just wanted to give you (and others) a quick update.
Hi @IanDBird, great that you are providing a solution for this! One question only - in my setup (Shield -> HDMI -> ARC-splitter -> TV -> Optical -> Audio system) I use the option optical passthrough so that AC3/DTS gets passed through via optical. I’m wondering if turning off optical passthrough will lead to only 2.0 PCM getting delivered?
I’ll try and answer by summarising what the setting does, and what is different when it’s enabled…
When Optical Passthrough is enabled:
If the source video uses AC3 or DTS, and that codec is “checked” for passthrough (via the preference), it will just be direct played
If the source video includes a multi-channel audio stream of an audio codec not “checked”, the server will be asked to transcode to one of the supported codecs.
If the Passthrough preference is configured for HDMI, we query what audio encoding support is communicated via the HDMI handshake. So will differ in each setup. However, in this scenario, when an audio codec is not supported, we allow 5.1 PCM over HDMI since that is always supported (the bandwidth of HDMI allows it).
If the Passthrough preference is completely disabled, we will use the devices local decoding capabilities (including additional decoders we’ve added) to decode supported audio streams. If they are above 2 channels, we will often try to output up to 5.1 PCM and allow Android TV to downmix when it requires.
Does this mean that you’ve slightly modified the optical passthrough option? Because on the current version, if you disable DTS in the options and you watch a video with DTS it down mixes to stereo rather than transcodes to AC3 which would be the preferred option.
I’m not sure if the HDMI option will work, will be interesting to try it out, I have a HDfury vertex so I might be in a position to fake the EDID information with the HDMI option so that it all works, but I’m slightly concerned that the HDMI option will say DTS and I’ll end up in the same situation.
The first option of optical passthrough transcoding DTS to AC3 is the ideal situation, if the codec is disabled it should transcode to the most appropriate codec, i.e AC3, if AC3 was disabled then it should transcode to PCM stereo.
Thanks for all your efforts Ian, I hope that we can soon put this one to bed.
(BTW, I’d be happy to test a beta right now if you were able to send it to me!)
As I mentioned in an earlier post, with the recent change, any “unsupported multi-channel audio” will be transcoded to something that is supported. So in the particular scenario you’re mentioning, a DTS track where DTS passthrough via optical isn’t enabled, should result in it being transcoded by the server to AC3.
I’m sorry, but my change is still in review and we can’t release an updated beta until our current RC (which is in beta) gets publicly released.
