Some AC3 tracks in passthrough mode have issues with seeking (ShieldTV 6.0)

[drhill]

On a few (at least one I can reproduce easily) shows with AC3 tracks being passed through to my receiver when I do a 30 second seek forward (or sometimes it takes 2-4 seeks) the current time becomes a horrible large number.

The problem occurs in exoplayer's AudioTrack.java AudioTrackUtil.getPlaybackHeadPosition() function here:
if (lastRawPlaybackHeadPosition > rawPlaybackHeadPosition) {
// The value must have wrapped around.
rawPlaybackHeadWrapCount++;
}
lastRawPlaybackHeadPosition = rawPlaybackHeadPosition;
return rawPlaybackHeadPosition + (rawPlaybackHeadWrapCount << 32);

This is on an Nvidia Shield TV with 6.0 (API 23). Whether I cheat and force needsPassthroughWorkaround = true (by removing the version check) or not. My "fix" was to comment out the increment of rawPlaybackHeadWrapCount. Not a good idea since I'm sure that is there for a good reason, but perhaps lastRawPlaybackHeadPosition should be checked to see if it is near a wrap threshold?

I can provide an episode on Google Drive if needed.

[andrewlewis]

It would be good to find out why the playback head position is jumping backwards. Please do send a link to the media and details of what platform build you're using on the Shield device. Thanks!

[drhill]

I sent a google drive link to the exodev email address.

Shield details are
Build MRA58K.41937_695.6426
3.1(24.5.78.96)

ExoPlayer commit: 5b79ef5

[drhill]

I made a temp fix in my own branch here: drhill@105cf7c

I pulled the 10000 out of thin air but it works for me so far.

[andrewlewis]

When seeking we create a new AudioTrack. On this device, the new passthrough AudioTrack's playback head position increases from the old AudioTrack's playback head position for a short time before jumping back to zero, but we expect it to start from zero.

I've followed up with Nvidia, as it seems to be specific to this device.

[drhill]

Thanks. I'm sure my temp fix will work fine for me locally as it only seems to happen on certain tracks (OTA recordings with reencoded video but I'm not sure if the audio track was touched) and it is only a seeking issue. No seeking, no problem in the current code, but I don't suspect I have any DD tracks that would get anywhere near the overflow check.

Nvidia seems to have some audio issues. I tried to implement TrueHD streaming (using their encoding type == 13) in ExoPlayer's AudioTrack class but only ended up with quick snippets of audio followed by massive underruns.

Should I close this or just leave it open?

[andrewlewis]

Let's leave this open to track the bug, in case we have a fix or clean workaround in ExoPlayer.

[cncb-gh]

Any word if NVidia will be providing a fix soon?

[andrewlewis]

We expect the fix will be included in the next system update.

[Displayel]

and thtat will be approximately when ?

[ojw28]

That's a question you'd have to direct to nVidia. You may also be able to get some idea or expectation by looking at their historical release cadence.