2014-08-06, 16:00
Apology accepted.
24p and passthrough is a real beast. The problem here is that TVs do some interframe calculation when doing 24p in order to make a correct cinema effect, post processing or compensate their cheap hw or something. Currently we don't get a single signal from the GPU on how A/V sync really is - there is no interface to query(*). We only know the sync by the timestamps we have from our renderer and from the buffer (e.g. delay) of the audio. If the hw does anything else internally to compensate whatever needs to be compensated we don't get clue of it.
A second problem is passthrough audio itself. You only have fixed size chunks of audio data, the only chance you have is either "drop" one of them or "dupe" one of them. The first makes clicks and the second is also not perfect.
Concerning the field of expertice: FernetMenta has currently rewritten the complete Audio Engine, which is running on more than 5 different platforms, starting from the Raspberry PI to Quad Core windows 8.1 systems ... we have the expertise, but the above mentioned problems are not easy to fix.
On my personal setup, I have an audio delay of nearly 0 when driving 50 hz and 60hz - I have a 24p delay of 175 ms, a friend of mine has 250 ms. As long as we don't get any knowledge from the hardware about this a/v delay, we cannot compensate.
Good news for this problem is, that this offset is constant per mode(!) - e.g. you can trim it one time and afterwards it's fine. For OpenELEC we ship and advancedsettings.xml which adds 175 ms delay for 24p and 24.0hz since nearly two years now - and average complaints got better.
(*) amd oss radeon reveals that information but it's not implemented in the ALSA kernel driver yet.
If your delay is "changing" over time - then it's another problem and we can probably do something from within xbmc.
24p and passthrough is a real beast. The problem here is that TVs do some interframe calculation when doing 24p in order to make a correct cinema effect, post processing or compensate their cheap hw or something. Currently we don't get a single signal from the GPU on how A/V sync really is - there is no interface to query(*). We only know the sync by the timestamps we have from our renderer and from the buffer (e.g. delay) of the audio. If the hw does anything else internally to compensate whatever needs to be compensated we don't get clue of it.
A second problem is passthrough audio itself. You only have fixed size chunks of audio data, the only chance you have is either "drop" one of them or "dupe" one of them. The first makes clicks and the second is also not perfect.
Concerning the field of expertice: FernetMenta has currently rewritten the complete Audio Engine, which is running on more than 5 different platforms, starting from the Raspberry PI to Quad Core windows 8.1 systems ... we have the expertise, but the above mentioned problems are not easy to fix.
On my personal setup, I have an audio delay of nearly 0 when driving 50 hz and 60hz - I have a 24p delay of 175 ms, a friend of mine has 250 ms. As long as we don't get any knowledge from the hardware about this a/v delay, we cannot compensate.
Good news for this problem is, that this offset is constant per mode(!) - e.g. you can trim it one time and afterwards it's fine. For OpenELEC we ship and advancedsettings.xml which adds 175 ms delay for 24p and 24.0hz since nearly two years now - and average complaints got better.
(*) amd oss radeon reveals that information but it's not implemented in the ALSA kernel driver yet.
If your delay is "changing" over time - then it's another problem and we can probably do something from within xbmc.
