[mythtv-users] Unusually high CPU utilization with DTS-HD MA

[Adam Stylinski]

So it appears to be thrashing on a QMutex in mythplayer.cpp in the
DecoderGetFrame function.  Can anyone think of a reason why it would
contending for the decoder lock way more around here when playing back
DTS-HD audio as opposed to normal DTS audio?

    if (!decoder_change_lock.tryLock(5))
        return false;
    if (killdecoder || !decoder || IsErrored())
    {
        decoder_change_lock.unlock();
        return false;
    }

    if (ffrew_skip == 1 || decodeOneFrame)
        ret = decoder->GetFrame(decodetype);
    else if (ffrew_skip != 0)
        ret = DecoderGetFrameFFREW();
    decoder_change_lock.unlock();
    return ret;

On Sat, Oct 25, 2014 at 8:31 PM, Adam Stylinski <kungfujesus06 at gmail.com> wrote:
> After running this code path through perf with and without DTS-HD it looks
> as though there is substantially more CPU time spent in IsErrored on the
> mythplayer class, and substantially more in mutexes with DTS-HD. When I can
> finally compile this without -fomit-frame-pointer I will know more.
>
> On Oct 19, 2014 2:14 PM, "Adam Stylinski" <kungfujesus06 at gmail.com> wrote:
>>
>> I replaced my GPU with a new one that supports HDMI HBR passthrough
>> and replaced my old audio receiver.  In doing so, after successfully
>> passing through DTS-HD MA to the receiver I noticed some strange
>> stuttering that I hadn't before.  At first I thought it was a
>> buffer/IO issue that could be mitigated by adjusting the
>> vdpaubuffercount variable, but after further testing it wasn't IO
>> related.  I noticed that whilst sending the DTS-HD audio to the
>> receiver the CPU utilization was substantially higher despite the GPU
>> doing the decoding (this is H264 video playback from a Matroska
>> container).  Switching the audio tracks to a non-HD audio track such
>> as regular DTS yielded very low utilization (< 10% on both CPUs, where
>> the CPUs were performing the deblock filtering).  Switching this again
>> back to DTS-HD the CPU utilization again spiked (on one core).  The
>> load is not steady, it is variable, but it peaks at 100% utilization.
>> Is this normal, and is there a fix for it?