[Krobar]

@Boilerplate4U Here is a build which increases the AE threshold variable:
https://drive.google.com/file/d/1RGXhpPC...sp=sharing

For me, it never works when I first start playing the file but if I then switch audio bitstream off and on again it gets an audio lock most of the time. This is the build used to produce the different log above. For me it works the same regardless of if I use original 29.97FPS framerate or double to 59.94FPS. Would be interested to hear if this build and the same bitstream on/off trick allows you to get some bitstream audio output from your Onkyo.

[Boilerplate4U]

@Boilerplate4U Here is a build which increases the AE threshold variable: https://drive.google.com/file/d/1RGXhpPC...sp=sharing

Thanks, I'll try that tomorrow.

Forgot to ask what you mean by "do you use the timing of the first frame or the last frame" Isn't PTS the same for all channels to be mixed or did you mean in which direction you start counting the offset from?

[Krobar]

Regarding PTS I've been trying to determine where the EAC3 frames should be buffered when SPF is <1536. If we combine EAC3 frames further up the chain (Nearer to FFMPEG/Decode) how do you return the PTS/timing for the group of up to 6 EAC3 frames?

Do you think the EAC3 frames could be buffered here?
https://github.com/xbmc/xbmc/blob/49a04c...AE.cpp#L86

[Boilerplate4U]

Hard to tell. I don't have the necessary insight in the code tree at the moment thus I need some more time to further investigate how things (like the AE classes) are meant to be used.

It's a pity the code base so consistently lacks comments that ought to explain how it's supposed to work, especially for a complex environment such as Kodi. The total absence of comments makes me think someone deleted those on purpose! ;-)

I'll see if I can find a tool to create a complete class tree for all the subsystems to get a better picture. Xcode for macOS has simple code analyser, I'll give a try...

[Boilerplate4U]

@Boilerplate4U Here is a build which increases the AE threshold variable:
https://drive.google.com/file/d/1RGXhpPC...sp=sharing

Hi! I've finally managed to get the build environment up and running for both v19.3 and v20 on Win10!

Can you show me what changes you made in the source code? I need this to build a debug version for my HTPC with capabilities for remote debugging. Then I can have a closer look how the output buffers are filled.

[Krobar]

For that build (Did it help on your setup?), I just changed the threshold variable from 100 to 600 here:
https://github.com/xbmc/xbmc/blob/49a04c....cpp#L2367

I have also tried moving the DD+ packet combining from AEBistreamPacker.cpp to DVDAudioCodecPassthrough.cpp but this did not help with that 256SPF file at all. It did seem to make detection of the much more compatible 768SPF file more reliable in my setup though. This 768SPF file is also useful for testing, it works on 99% of receivers as it produces far less blank frames but it is useful to check if the DD+ packet combining still partly works / has not been made worse:
https://drive.google.com/file/d/1yu89SOH...sp=sharing

[Boilerplate4U]

Had some odd trouble with the runtime debug libraries for remote debugging but now everything is up and runnnig on my HTPC. For unknown reasons Microsoft has decided that the debug libraries are NOT to get installed with the remote debug toolkit(!). There is an option in VS to deploy them automatically using the "deploy" option in the configuration manager. But that causes trouble with compiling if you add in to the debug configuration so in the end I had to copy them by hand. 

Anyhow, where exactly did you spot the 6 empty frames so I can start debugging from there?

[Krobar]

Had some odd trouble with the runtime debug libraries for remote debugging but now everything is up and runnnig on my HTPC. For unknown reasons Microsoft has decided that the debug libraries is NOT to get installed with the remote debug toolkit(!). There is an option in VS to deploy them automatically using the "deploy" option in the configuration manager. But that causes trouble with compiling if you add in to the debug configuration so in the end I had to copy them by hand. 

Anyhow, where exactly did you spot the 6 empty frames so I can start debugging from there?

Glad to hear you got it working. The empty frames info came from my receiver manufacturer. After quite a bit of pestering I think they replicated a Kodi setup and used some sort of analyser. At first I wasn't sure if the info was correct but then after asking on AVS for feedback from other users it seems although many receiver cannot handle the current bitstream output with the 256SPF file some Denon/Marantz can which does somewhat support the manufacturer feedback. Were you able to at least get a lock with your Onkyo and the build with the increased threshold? (That might be a good place to start)

[Boilerplate4U]

Were you able to at least get a lock with your Onkyo and the build with the increased threshold? (That might be a good place to start)

For the moment I'm using a clean 19.3 to establish a baseline and to get a feeling where to look for the output buffers and set the corresponding break points. After that I'll use your changes and compare the output.

[Boilerplate4U]

Hi, sorry for not getting back to you but I've been busy at work and sick kids at home. 

Just some quick questions, what audio settings are you using in kodi ie directsound/wasapi and/or separat settings for passthough etc? Also, what type of connection are you using between your htpc and avr, ie just hdmi (1.4 or 2.0?) or/and toslink?

[Krobar]

Hi, no problem I have not looked at it for over a week either.

I'm using WASAPI with all bit streaming options enabled. If you disable bit-streaming for Dolby / Dolby Digital Plus you should find the file plays fine as multi-channel PCM.  I'm using HDMI 1.4 from an Intel iGPU, for my setup this ensures 3D works (With an appropriate Kodi build) as there is no LSPCON in the chain (Native HDMI). Toslink with DD+ (Not legacy DD) is very hit and miss, quite a few AVRs will allow it as a result of the old ARC standard but I don't think WASAPI/Windows will allow DD+ over Toslink and it is questionable if DD+ over Toslink is within spec.

[Dukar]

HDMI requires that EAC3 packet be combine to a total of 1536 Samples Per Frame. Source media can be 256, 512, 768 or 1536 SPF with 1536 SPF being by far the most common (Which requires no packet combining at all). The sample I provided is the most extreme 256SPF case so 6 audio samples from the source file need to be combined into one HDMI audio packet.

My current thinking is the existing mechanism to combine these packets is being done in the wrong place, if we combine the DD+ frames much nearer to FFMPEG then we wont generate blank audio frames. I dont understand the synching yet either but my thoughts are if the audio packets rate is decided with knowledge of the SPF it can be effectively set 6 times lower for 256SPF and then the timing problems will probably fix themselves. The other thing I don't quite understand is how you deal with the PTS offset when your combined HDMI audio frame is a combination of 6 audio frames from different PTS time stamps, do you use the timing of the first frame or the last frame?.

HDMI's EAC3 combining and timing complexities raise questions about optimal packet handling. Syncing and timing issues might be resolved by combining frames closer to FFMPEG and adjusting audio packet rates accordingly. PTS offset handling requires careful consideration.

[Krobar]

Sounds right. My C skills are nowhere near what is needed to resolve this; I was hoping the recent EAC3 improvements to handle native EAC3 frame + extension would look at his but no luck. If you have a non-Denon/Marantz HDMI receiver there is a good chance it wont tolerate the current number of blank frames with a 256SPF source; can send a sample file and try to help if you are willing to look at it.