<div dir="ltr">Hi<br><div class="gmail_quote"><div dir="ltr">Am Sa., 26. Mai 2018 um 11:47 Uhr schrieb Alexander E. Patrakov <<a href="mailto:patrakov@gmail.com" target="_blank">patrakov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2018-05-25 22:15 GMT+08:00 Arun Raghavan <<a href="mailto:arun@arunraghavan.net" target="_blank">arun@arunraghavan.net</a>>:<br> > On Tue, 22 May 2018, at 4:32 PM, Alexander E. Patrakov wrote:<br> >> There is some Microsoft documentation that contradicts this code.<br> >><br> >> <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dd316761(v=vs.85).aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-us/library/windows/desktop/dd316761(v=vs.85).aspx</a><br> >><br> >> """<br> >> Dolby TrueHD (MAT)<br> >><br> >> Dolby TrueHD content is transmitted over IEC 60958 at 176.4 kHz / 8<br> >> channels (requiring an IEC 60958 frame rate of 705.6 kHz) for content<br> >> sample rates of 44.1, 88.2 and 176.4 kHz, and 192 kHz / 8 channels<br> >> (requiring an IEC 60958 frame rate of 768 kHz) for content sample<br> >> rates of 48, 96 and 192 kHz.<br> >> """<br> ><br> > Based on Peter's input in a private thread, seems this is not the case on Linux:<br> ><br> > <a href="https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L135" rel="noreferrer" target="_blank">https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L135</a><br> > <a href="https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L486" rel="noreferrer" target="_blank">https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L486</a><br> <br> I have looked, and also obtained a copy of IEC 61937-5-2006 standard,<br> and I think I understand where this discrepancy comes from. The issue<br> is that the standard does not define at all what to do if the sample<br> rate of DTS audio is not a multiple of 48 kHz. I.e., it does not even<br> cover the DTS CD case (44.1 kHz) that de-facto exists!<br> <br> Still, I think that diverging from what Windows does is not a good<br> thing. Has anyone tested that passthrough works with DTS-HD streams<br> that are not with a sample rate that is a multiple of 48 kHz? Does<br> anyone have such DTS-HD stream at all?<br></blockquote><div><br></div><div>We are using this in kodi since first introducing HBR bitstream support. For DTS our sync code also can cope with 44.1 khz. But recently an issue occured for DTS-HD HR vs. DTS-HD MA that some new receivers don't like being sent 192/8, see this discussion here: <a href="https://github.com/Nevcairiel/LAVFilters/issues/167">https://github.com/Nevcairiel/LAVFilters/issues/167</a> - this most likely means that we have to distinguish between different DTS-HD formats. Hendrik's workaround was: <a href="https://github.com/Nevcairiel/LAVFilters/commit/3ec0521e8aa68047c08fa9d518327e6fd36c827d">https://github.com/Nevcairiel/LAVFilters/commit/3ec0521e8aa68047c08fa9d518327e6fd36c827d</a> sending 192 khz / 2 channels for HR bitrates.</div><div><br></div><div>Peter</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> ><br> > Cheers,<br> > Arun<br> ><br> >> 2018-05-22 12:13 GMT+08:00 Arun Raghavan <<a href="mailto:arun@arunraghavan.net" target="_blank">arun@arunraghavan.net</a>>:<br> >> > In high bitrate mode, we force 192kHz/8ch as the sample format, which is<br> >> > the expectation for HBR formats (as that is what allows for the largest<br> >> > possible packet size).<br> >> > ---<br> >> > src/pulsecore/core-format.c | 3 +++<br> >> > 1 file changed, 3 insertions(+)<br> >> ><br> >> > diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c<br> >> > index 862a74b5d..096acc3a2 100644<br> >> > --- a/src/pulsecore/core-format.c<br> >> > +++ b/src/pulsecore/core-format.c<br> >> > @@ -248,6 +248,9 @@ int pa_format_info_to_sample_spec_fake(const pa_format_info *f, pa_sample_spec *<br> >> ><br> >> > if (f->encoding == PA_ENCODING_EAC3_IEC61937)<br> >> > ss->rate *= 4;<br> >> > + else if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) ||<br> >> > + (f->encoding == PA_ENCODING_DTSHD_IEC61937))<br> >> > + ss->rate = 192000;<br> >> ><br> >> > return 0;<br> >> > }<br> >> > --<br> >> > 2.17.0<br> >> ><br> >> > _______________________________________________<br> >> > pulseaudio-discuss mailing list<br> >> > <a href="mailto:pulseaudio-discuss@lists.freedesktop.org" target="_blank">pulseaudio-discuss@lists.freedesktop.org</a><br> >> > <a href="https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss</a><br> >><br> >><br> >><br> >> --<br> >> Alexander E. Patrakov<br> <br> <br> <br> -- <br> Alexander E. Patrakov<br> </blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-3812856211522582881gmail_signature"> Key-ID: 0x1A995A9B<br> keyserver: <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>==============================================================<br>Fingerprint: 4606 DA19 EC2E 9A0B 0157 C81B DA07 CF63 1A99 5A9B</div></div>