[Jönke]

The Ezcco splitters are cheap on Amazon and works good 
”EZ-EX11HAS-PRO”

[Hitcher]

That won't output Atmos though.

[Draconix]

This might be a slightly different issue, but I'm having a TrueHD audio dropout issue with the blu-ray of "Lightyear". Every 5-10 minutes the sound will cut out for a split second.

I haven't had any TrueHD issues with any other files since the advanced setting "maxpassthroughoffsyncduration" was added.
The only film with this issue is "Lightyear", it's really strange. I'm wondering if anyone else has noticed this?

EDIT: I tested it on the latest master build and also the MAT Packer build, the problem is the same on both.

[fritsch]

This might be a slightly different issue, but I'm having a TrueHD audio dropout issue with the blu-ray of "Lightyear". Every 5-10 minutes the sound will cut out for a split second.

I haven't had any TrueHD issues with any other files since the advanced setting "maxpassthroughoffsyncduration" was added.
The only film with this issue is "Lightyear", it's really strange. I'm wondering if anyone else has noticed this?

EDIT: I tested it on the latest master build and also the MAT Packer build, the problem is the same on both.

I am wondering when you learn to post debuglogs ... especially if you can reproduce the stuff every 5 to 10 minutes ...

[Hitcher]

The only film with this issue is "Lightyear", it's really strange.

Sample please for testing.

[Draconix]

I am wondering when you learn to post debuglogs ... especially if you can reproduce the stuff every 5 to 10 minutes ...

Apologies, I was busy yesterday. Here's the debug log: https://paste.kodi.tv/edigaluhen.kodi
I noticed 4 dropouts while making this log.
 

Sample please for testing.

The dropouts seem pretty random, so I'm not sure a sample would help. I'd have to probably make a 10 minute sample, but that's probably too long and might be a copyright issue.

[fritsch]

I am wondering when you learn to post debuglogs ... especially if you can reproduce the stuff every 5 to 10 minutes ...

Apologies, I was busy yesterday. Here's the debug log: https://paste.kodi.tv/edigaluhen.kodi
I noticed 4 dropouts while making this log.
 

Sample please for testing.

The dropouts seem pretty random, so I'm not sure a sample would help. I'd have to probably make a 10 minute sample, but that's probably too long and might be a copyright issue.

Very good one. Fits int the new truehd testing build thread. You have a sample that stimulated the packer.

[jogal]

xml:
2024-05-01 17:36:46.119 T:18383 warning <general>: PackTrueHD: detected a stream discontinuity -> output timing expected: 35328, found: 35368

2024-05-01 17:36:46.119 T:18383 warning <general>: WritePadding: a large padding block of 114410 bytes is required due to unusual timestamps

2024-05-01 17:36:46.120 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:37:56.529 T:18383 warning <general>: WritePadding: a large padding block of 107910 bytes is required due to unusual timestamps

2024-05-01 17:38:10.181 T:18383 warning <general>: WritePadding: a large padding block of 113610 bytes is required due to unusual timestamps

2024-05-01 17:38:10.181 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:38:58.982 T:18382    info <general>: Skipped 1 duplicate messages..

2024-05-01 17:38:58.982 T:18382   debug <general>: ActiveAE::SyncStream - average error 103.736363 above threshold of 100.000000

2024-05-01 17:38:58.984 T:18382   debug <general>: ActiveAE::SyncStream - average error 23.736363 below threshold of 30.000000

2024-05-01 17:41:16.462 T:18383 warning <general>: PackTrueHD: detected a stream discontinuity -> output timing expected: 32160, found: 32200

2024-05-01 17:41:16.467 T:18383 warning <general>: WritePadding: a large padding block of 108222 bytes is required due to unusual timestamps

2024-05-01 17:41:16.467 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:41:46.362 T:18383 warning <general>: WritePadding: a large padding block of 111394 bytes is required due to unusual timestamps

2024-05-01 17:41:46.363 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:41:50.032 T:18382   debug <general>: ActiveAE::SyncStream - average error 103.927892 above threshold of 100.000000

2024-05-01 17:41:50.032 T:18382   debug <general>: ActiveAE::SyncStream - average error 23.927892 below threshold of 30.000000

2024-05-01 17:42:11.707 T:18383 warning <general>: WritePadding: a large padding block of 105870 bytes is required due to unusual timestamps

2024-05-01 17:42:11.707 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:42:54.804 T:18383 warning <general>: WritePadding: a large padding block of 108086 bytes is required due to unusual timestamps

2024-05-01 17:42:54.806 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:43:39.344 T:18383 warning <general>: WritePadding: a large padding block of 111300 bytes is required due to unusual timestamps

2024-05-01 17:43:39.348 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

2024-05-01 17:43:40.624 T:18382    info <general>: Skipped 1 duplicate messages..

2024-05-01 17:43:40.624 T:18382   debug <general>: ActiveAE::SyncStream - average error 105.384219 above threshold of 100.000000

2024-05-01 17:43:40.624 T:18382   debug <general>: ActiveAE::SyncStream - average error 25.384219 below threshold of 30.000000

2024-05-01 17:43:56.837 T:18383 warning <general>: WritePadding: a large padding block of 109510 bytes is required due to unusual timestamps

2024-05-01 17:43:56.837 T:18383   debug <general>: FlushPacket: several MAT packets generated in a row, the size of the output queue is 2

All logs lines are due same thing: the main issue is missing some TrueHD audio units or bad time stamps:

output timing expected: 35328, found: 35368  ---> difference is 40 frames or samples, this is exactly one TrueHD unit = 1/1200 s = ~0.83 ms

Since audio data is missing, extra padding is generated (a large padding block of 114410 bytes is required due to unusual timestamps)

In some streams it is possible to see sporadic errors like these without any dropout occurring. This is because the specification allows this padding to exist (even blocks larger as ~300,000 bytes) when there is an intentional jump. e.g. seamless branching Blu-Ray's.

But in this case it seems like a different thing since the player also needs to synchronize the audio/video:

xml:
2024-05-01 17:38:58.982 T:18382 debug <general>: ActiveAE::SyncStream - average error 103.736363 above threshold of 100.000000

2024-05-01 17:38:58.984 T:18382 debug <general>: ActiveAE::SyncStream - average error 23.736363 below threshold of 30.000000

So for me this stream has something wrong. Maybe the audio was from another source at 24.0 fps instead of 23.976 fps, etc. I don't think there is any solution for this.

The important concept is that in some streams there may be discontinuities (which will give rise to records in the log) without producing audio dropouts/cuts. These would be the cases in which the new TrueHD packer would work better than the previous one.

One example of this is "Cars (2006)", at least playing BDMV structure directly (.m2ts)

[Draconix]

So for me this stream has something wrong. Maybe the audio was from another source at 24.0 fps instead of 23.976 fps, etc. I don't think there is any solution for this.

This file is a Remux of the Lightyear Blu-Ray disc. It's possible, but I doubt that Disney would make such a huge error when making the Blu-Ray.

I also tried watching the first 30 minutes of the same file on my PC using VLC and it played perfectly with no dropouts, and I didn't see any A/V sync issues either.
Should I maybe try installing the release version of Omega to test the file? It should be a more stable build from before the implementation of the new MAT Packer, so we can maybe see if the issue is related to the that.

EDIT: I decided to try reverting to the stable v21 Omega release, but it didn't help. So I think it's safe to say that the MAT Packer isn't the problem.
           However this file seems to play perfectly fine on everything else... the audio dropouts only happen in Kodi.

[fritsch]

So for me this stream has something wrong. Maybe the audio was from another source at 24.0 fps instead of 23.976 fps, etc. I don't think there is any solution for this.

This file is a Remux of the Lightyear Blu-Ray disc. It's possible, but I doubt that Disney would make such a huge error when making the Blu-Ray.

I also tried watching the first 30 minutes of the same file on my PC using VLC and it played perfectly with no dropouts, and I didn't see any A/V sync issues either.
Should I maybe try installing the release version of Omega to test the file? It should be a more stable build from before the implementation of the new MAT Packer, so we can maybe see if the issue is related to the that.

EDIT: I decided to try reverting to the stable v21 Omega release, but it didn't help. So I think it's safe to say that the MAT Packer isn't the problem.
           However this file seems to play perfectly fine on everything else... the audio dropouts only happen in Kodi.

VLC with passthrough? Your dropouts most likely are gone in kodi as well if you disable TrueHD passthrough.
So what do we compare here?

[Draconix]

VLC with passthrough? Your dropouts most likely are gone in kodi as well if you disable TrueHD passthrough.
So what do we compare here?

You're correct, I didn't even consider that. Well I'm still hoping we can try to find a solution, just in case this affects other Blu-Rays in the future.

If there's nothing we can do, then I guess we have to hope this was just a one-time anomaly.

[jjd-uk]

The Lightyear movie is a mkv file, and Disney don't provide media in mkv files, so did you rip it yourself direct from disc? If not then perhaps try a different supplier 😉

[fritsch]

There might be something else: as you know audio engines delay is based on the sinks feedback which is at the end samples towards samplerate in the format the sink is opened. When AE now adds 16 Ms auf Audio but gets back a changed delay of 100 ms, then it will bail out.

From what I see here the physical relation between sink delay and semantic payload goes wrong or in other words: AEs timing does not adjust when packer generates more values. This was not a problem with the one size fits all approach.

[Draconix]

@fritsch, I'm willing test any potential fixes and make debug logs in case you want to try something.

Otherwise if you think this is just an incorrectly created Remux, then don't worry about it. Though it would be nice to implement something that makes the audio engine more robust when dealing with instances like this.

[fritsch]

AE with iec passthrough has a very simple relation: every truehd packet that is sent packed to the sink has a fixed size in milliseconds and the packed data results in the same time but in sink units.

Example: your sink has 192 khz, 16 bit and 8 channels. That is for one second of sink payload: 192000 x 2 x 8 Bytes per second equal to 1 second of audio. Means if you want to send 1s truehd audio you need to make sure that it is packed in a way to consume all the bandwidth that is available.

If the relation does not match, sink's getdelay won't fit to AE's expectation.