Kodi can playback DSD (.dsf files), and with recent versions of MusicBrainz Picard being now able to add metadata to them (as well as DTS .wav files now) and kodi being able to read those tags, I thought I was all set to just rip and store my sacds as dsf, on the theory that the original raw data is always going to be more “pure” than any trans-coded version.
However, when you playback a codec such as DSD on the Vero4k, it decodes and sends PCM to the receiver. I think I read that doing so causes excessively high CPU use, and effectively constitutes electronics abuse.
Is this because DSD pass-through cannot be handled by the HDMI spec itself? Or is it a limitation of the Vero hardware? Or a licensing limitation? Or just that kodi doesn’t support it (yet)? That is to say, is DSD pass-through something that Just Isn’t Going To Happen, and I would be better off re-ripping those SACDs back to flac again and skip saving as dsf to save the wear-and-tear on the Vero? or should I hold onto the DSF files for the future?
Does the same thing apply to MLP (raw DVDA sound files), which kodi can also play, (also by sending as PCM according to the info on my receiver). For MLP playback, CPU seems to hover around 50%, rather than the 180% that DSD is showing, so doesn’t seem to be as bad, although there’s no gapless playback with it.
The Vero 4K + has thermal governing, so if you’re asking if you can damage your device by using CPU intensive workloads, then the answer is not really. There were older versions of OSMC where we weren’t throttling the right workloads enough, but this should be significantly improved in recent updates.
We have thermal trip points where we start to reduce performance to prolong longevity and prevent damage to the device.
Actually, for MLP, I compared cpu usage for playing the .mpl with the cpu for playing the same file converted to flac. mlp in the 30-50% range, flac in the 50-60% range (for a 4.1 quad track from DVDA). So seems that mlp is actually easier on the cpu then flac.
Ok, so DSD shouldn’t break anything (though I think I do occasionally see hangs), but will pass-through ever be a thing? Or, since it’s going to always be PCM anyway, should I just convert to flac?
Not a topic I follow but I looked around quite a bit a year or so ago just to inform myself and If I recall correctly I think this thread was the most informative regarding the passthrough topic…
The answer is pretty simple and also answered in our audio wiki… Vero simply can’t output DSD via pass-through. There’s a HDMI spec for it, but it’s not something that any Kodi device we know of has implemented. Not all AVR support that pass-through format, but some do.
Pretty unlikely really as it’s not a common case. @grahamh might be able to say more about this, but energy in our small team will most likely be directed elsewhere But we’re always listening to requests and if something gets enough support, we might look into it (not a guarantee that it will happen then either, for various reasons).
MLP is simply a packaging format for PCM audio, so nothing special to pass-through here.
AFIAK, MLP is a lossless compression so the equivalent of FLAC in processing terms. It’s also the basis of TrueHD so the plumbing should be there already for passthrough.
For 1-bit audio, even if the hardware could handle it (not sure about that), it would need some love from both Kodi and AMLogic.
MLP can’t be passed through as it’s not a passthrough format itself, it’s only the compression method… Dolby TrueHD is a passthrough format (or actually rather Dolby MAT) that relies on MLP for compression - don’t confuse the two, compression and passthrough format
If MLP compressed data is not packed in a Dolby MAT container, it can’t be passed through, it can only be unpacked/decompressed and passed on as PCM audio, which is fine - there’s e.g. no 3D audio metadata that has to be preserved.
It’s the same as FLAC or AAC can’t be passed through: They’re file/compression formats, not passthrough formats.
OK, so we would have to pack the MLP into MAT to pass it on to an AVR. That would need some Dolby voodoo which we don’t have the knowledge of. So it’s not going to happen.
And it’s simply not necessary as it makes absolutely no difference quality-wise. Even if we could pull it off, it might increase CPU usage a lot more to pack MLP-compressed audio data into a Dolby MAT stream than to simply decompress MLP to PCM and output it…
But we’re always listening to requests and if something gets enough support, we might look into it (not a guarantee that it will happen then either, for various reasons).
