DTS audio drop outs

[blenky]

(07-26-2010 05:23 PM)kavorka Wrote:  I'm pretty lost now. My popcorn hour also suffers from the dts drop outs. What's the best work-around to solve this?

1) MKVextract and then merge?
2) Remux to .ts or .m2ts?

I find number 2 the quickest and, for me, 100% effective.

[chou]

best way to remux to .m2ts?

[blenky]

(07-29-2010 09:37 PM)chou Wrote:  best way to remux to .m2ts?

Get TSMuxer here.

[svu]

Could PLEASE anybody from PCH company comment if that issue is going to be fixed at all - for both 100 and 200 series? Or all we are going to have is remuxing workaround?

[HeartWare]

Point the finger at the appropriate target...

If a ReMux solves the problem, then it is the original mux that is the culprit - not the playback device. Blame the original muxer...

[svu]

(08-05-2010 08:35 AM)HeartWare Wrote:  If a ReMux solves the problem, then it is the original mux that is the culprit - not the playback device. Blame the original muxer...

How happened that other devices/players do not have that problem, with the same file? Is there a technical explanation on what's the difference between "bad" and "good" files (slightly deeper than just "incorrect muxing") - and, most important, do "bad" files actually violate the format specs - or they are just different (if so, there is a bug on PCH side)?

[HeartWare]

(08-05-2010 08:58 AM)svu Wrote:  How happened that other devices/players do not have that problem, with the same file?

Read Martian Headsets to learn why you can't conclude that just "because one program can play back some files, then all programs that can't play back the same file must necessarily be at fault".

[svu]

I understand that. That is why I asked the second question - whether "bad" files violate existing MKV standard or not (or perhaps they are just in "grey area")?

[HeartWare]

Since we do not know exactly why the DTS dropouts happen (and why it happens only on some setups and the exact same file plays back fine on another setup - but with the same playback device), we can't say.

My personal theory is that the audio (which is interleaved with the video in the .MKV file) is at a "wrong" distance from the video at certain points. Ideally, the video part and the audio part for the same time position of an .MKV file should be very close to each other, so that when the playback device reads the file, it'll get both the audio and video data in the same chunk. But if the audio part is too far away from the video part, then the playback device needs to do two reads from the storage device in order to get both the audio and video for a particular time position.

On some devices (both storage devices and playback devices) there's a bigger read-ahead buffer built in to the hardware, so this need to do two reads doesn't take any significant amount of time, but if the storage device that contains the file only have, say, 16Kb read buffer, and the distance between the video and the audio part of the time position is 20Kb, then the storage device needs to do a physical read of another 16Kb, and if this doesn't happen soon enough to deliver the audio data to the audio decoder, then you'll get audio dropouts.

This also explains why - if you rewind back over the drop-out time position - it'll play back fine on second run. This is because both the storage device and the playback device have a cache (which is usually many times bigger than the read-ahead cache) where it keeps the latest read data from the file, and since the part of the file that caused the drop-out already is in the cache, there's no physical read needed, and thus the time to deliver the audio data to the audio decoder is significantly lower this time around.

A ReMux will re-do the interleaving of the audio and video to put these two parts closer together so that both the video and the audio will be read by the same single read-ahead buffer, and thus the audio data is ready to be delivered to the audio decoder on time.

That's just my personal suspicion of what's going on...

And since there's no official guideline (AFAIK) as to how far apart the audio and video part must be in order for the file to be "standard", you can't say that the file is "bad", nor can you say that the playback device is at fault... You can only say that this particular combination doesn't work...

[svu]

Thank you very much, your explanation makes sense. Is there any way to increase the OS read-ahead buffer size on PCH? Or the media player software buffer size? From your explanation, that might help, right?

[HeartWare]

There's no (known) way to increase the buffer at any of the relevant locations, except to buy a storage device (HDD) with a large read-ahead buffer (don't ask me which one - I don't know).

[svu]

what about hdparm: readahead param?
or sysctl param vm.min-readahead (and max-readahead)?
Would they be of any interest?

[HeartWare]

I have absolutely no idea...

[svu]

I will try

[svu]

What I found:
hdparm already configured /dev/hda with readahead 512. I guess it is maximum.
sysctl does not have readahead params in that kernel.

Anyway, these params are for local filesystem only - they would not help with SMB.

Now, the biggest question is the following: is there any way to customize /bin/mono read-ahead buffer size?. Who could know?

PS BTW, changing PCH audio output for DTS from DTS to Analog can be used as workaround - the drop outs disappear. But of course quality suffers