This would probably require a change to Kodi rather than OSMC, but I guess there’s no harm in asking.
At the moment, on the Vero 4K+, there is some (to my mind) odd behaviour associated with pass-through and DTS-HD. If you set it to pass through DTS-HD, that works fine (as far as I know); similarly, if you set it not to pass through anything, that’s also okay.
But if you set it to pass through DTS, but not to pass through DTS-HD, and then you play a DTS-HD audio track, what I would have expected to happen is for it to decode the audio track I’ve told it to use (DTS-HD) and output that as multi-channel PCM; but what it actually does is to extract the core DTS track, and output that with pass-through, thus compromising my audio experience.
One can work around this by telling it not to pass through plain DTS either; and I guess the thinking behind it is that relatively few receivers are able to handle multi-channel PCM at all if they can’t handle DTS-HD; but even so, it still doesn’t seem logical that it is (effectively) not playing the audio track it’s been told to play.
Could an extra setting be added to select what to do in that situation? (Or could the default behaviour be changed?)
The first question coming to my mind would be: Why passthrough non-HD audio, but not HD-audio? Or rather: Why decode the HD format to LPCM and not the non-HD one - which would have absolutely the same effect? 
As DTS-HD is a format based on a DTS core, it’s absolutely logical IMHO that the core is sent, if you set DTS passthrough to on. The behaviour will be different with Dolby TrueHD or Digital+ as those don’t have a Dolby Digital core…
If you have a receiver that can decode DD, DD+ and DTS, and that can handle multi-channel PCM, but which can’t decode TrueHD or DTS-HD, wouldn’t that be the most logical configuration? Obviously it’ll sound the same if you don’t pass through anything, but it’ll offload the Vero’s CPU a little bit in cases where the receiver can do the decoding.
You shouldn’t notice the difference in any scenario. Just disabling passthrough alltogether would make much more sense than a big coding effort for a corner case more and more unlikely to be needed - as most AVRs can decode basically anything nowadays. And as decoding everything to LPCM makes no difference at all in audio quality.
The problem is not that there isn’t a work-around, the problem is that the way it works now is highly counter-intuitive. I expected it to already work the way I’m describing, and was surprised that it doesn’t. If you check out this recent thread you’ll see that two other people there make precisely the same assumption. As it stands, people are going to get sub-optimal audio without necessarily realising that they are.
That’s why we have an audio wiki article explaining all of this in detail.
Have you checked to see how much CPU is used by having the Vero decode lossless audio? The difference in CPU consumption is well within the margin of error for the display from top.
Basically, if your AVR can handle 7.1 LPCM over HDMI but not some of the lossless formats, you should have the Vero decode everything so that the decoded lossless is always sent to the AVR.
I agree, it is a setting that needs a bit more documentation, but there are a lot of those in Kodi.
I think a better option may be to have an auto mode which can automatically set default audio settings based on the EDID
1 Like
I took a quick look at the wiki here and on Kodi and was not seeing the issue at hand mentioned. After that previous thread I did some digging to understand exactly what was going on, and why, and it was not exactly the easiest thing to nail down. The issue with DTS-HD passthrough affects every Raspberry Pi so i’m not sure it is really an edge case. The way Kodi treats most sound is that it does passthrough for what is selected and everything else goes to LPCM or AC3 depending on your settings. The current behavior for DTS-HD acts differently as for whatever reason it dumps to DTS-Core instead of the expected fallback. So for someone who doesn’t know better they think they are getting that uncompressed DTS if their source and AVR have DTS-HD but they are not, unless they turn off DTS, which I don’t think is intuitive.
I think if there was an option to select if you wanted to render to core or not it would actually make more sense.
It’s a logic which is probably not intuitive for many, we can agree on that. I guess, the logic behind this is (and I can only guess as this logic is Kodi’s, not ours!) looking strictly at how the sound formats work, not so much at what a user would expect to happen. If you enable DTS passthrough, it’ll passthrough the core of DTS-HD as it’s the inherent fallback of that format… Or in other words: there’s a DTS track available, so it’s being passed through. But it just doesn’t make much sense to only decode half of the formats and pass through the rest. You’ll find this logic in most BD players as well: if passthrough is enabled, it won’t decode DTS-HD to LPCM, if the receiving device advertises only lossy DTS capabilities, as it offers a lossy core track. Only when disabling passthrough, it’ll decode everything to LPCM.
So, again… Why would you decode half of the formats and not the lossy half as well? If you simply disable passthrough, like you’d probably do with a BD player, it’s all working as expected without any loss of audio quality. Simple as that 
With a hardware player that did not support HD it would output core regardless of the settings as an inherent limitation.
With a hardware and software that is not constrained the same way why would the default setting be sub-optimal.
The default setting is passthrough being disabled on our device… Which would also solve this scenario very conveniently. The question remains: Why passthrough DTS and Dolby, but only decode DTS-HD and Dolby Digital+/TrueHD to LPCM?
By default behavior I meant that the fallback for HD audio (going to core) is different than non-HD audio when you are using passthrough.
The reason why would be to maximize quality. If my AVR can do it I would be willing to bet it would do a better job than my player. It just so happens that with DTS-HD there is a 192khz snafu so for that particular format having the player output LPCM means I get uncompressed audio where I wouldn’t otherwise.
I’m not trying to criticize anyone’s choices, and i’m not going to champion a cause here. The issue can be worked around quite easily once you understand what is going on. More than anything I’m just someone who has been playing with Kodi since the original Xbox and if I got tripped up on this topic then perhaps there is room for improvement.
From the format logic, the behaviour is the same… DTS is the fallback for all DTS formats. If you disable DTS passthrough it has to be decoded to PCM as there’s no other fallback anymore.
Sry to disappoint, but this is simply not the case. It absolutely doesn’t matter which device decodes an audio format like DTS-HD to LPCM because it’s simply a mathematical conversion. Any device can do it and there’s no difference in the resulting audio quality.
LPCM supports the same audio channels, bit-depths and sample rates as DTS-HD does. When decoding it to LPCM where is the difference?
Although almost every DTS-HD soundtrack is only 48khz the DTS-HD bitstream requires 192khz. So for a device such as the Pi, that does not have hardware support for 192khz you have to go to LPCM to get the uncompressed version out. The unituitive part is that…
DTS passthrough off:
DTS=lossy
DTS-HD=lossless
DTS passthrough on:
DTS=lossy
DTS-HD=lossy
We’ll change the wiki in that regard. If you’d like to get the best experience with your non-HD audio, LPCM-capable AVR, you should disable passthrough. That should cover it.
The issue has to do with the player, not the AVR. I would probably word it more like this…
If you choose passthrough for AC3 or DTS and are not passing through their respective HD formats then the resulting output for all HD audio source material will be only the non-HD core. If you disable passthrough all HD audio source material will be processed as HD.
As this isn’t true for Dolby TrueHD which has no core track by design (only a lossy companion track sometimes), this would be misleading. Simply disabling passthrough is the best option here… And the wiki should state so.
One obvious reason is that it allows the AVR to tell you what the player is doing if you suspect that it’s not doing what it should.
Suppose, for example, you’re playing something using the Netflix plug-in and you want to know if the player is really accessing the Dolby Digital Plus audio stream, or if it is falling back internally to plain Dolby Digital: if everything is output as LPCM, there’s no easy way to distinguish between the two.
Similarly, if you suspect the player might be incorrectly dropping back to a core DTS track rather than using a DTS-HD track, it’s less easy to test for that if both are output as PCM.
But I think we’re getting a little sidetracked with questions like that. The key issue is still that what the player does is not what people expect it to do. It’s no use saying “It’s in the wiki” unless people are actually going to read the wiki; and I think most people are probably like me: they will skim the available documentation until they understand roughly what’s going on, and then come back to it and read it in detail only when something is not working correctly.
In this case, pass-through seems like a fairly simple concept: if pass-through is on, the player passes through the raw audio bitstream, and if it’s off, it decodes it to multichannel PCM and outputs that instead. People will read enough of the documentation to grasp that concept (or even not read it, but just post on here asking “what is pass-through?” and get an answer similar to that). They won’t read the fine detail unless they know something is wrong.
And the point is that they may not notice something is wrong for quite some time. When they finally realise they’ve been getting substandard audio for the past couple of months, then maybe they’ll look at the wiki, and read the part that says “turning pass-through off means that the player will decode the selected audio track and output it as PCM in all cases except DTS-HD where it means something completely different”.
That seems like a good option, so long as you can rely on the EDID being correct. I don’t know often you can. I know that 2016 LG OLED TVs, for example, have a buggy audio EDID which says that they can’t accept a Dolby Digital Plus signal when, in reality, if you force DD+ they actually handle it just fine.
But yeah, probably in the majority of cases it would make sense to set up pass-through automatically, so long as that caters for the specific situation being discussed here.