Topic: Occasional sound drops with TrueHD/LAV (Read 20933 times)

Jong · « **on:** January 16, 2013, 06:24:17 am »

I have this problem only with TrueHD, never with DTS-HD or other audio streams.

I am using ROHQ with WASAPI exclusive. I have tried both "regular" and event-style. Occasionally (maybe 2 or 3 times in a movie) audio will cut out for a fraction of a second in event style and crackle for a while then cut out for a briefer time with regular style (this exact behaviour may not be 100% consistent). I am trying increasing the WASAPI buffer to see if that helps, but I am curious if anyone else sees similar with TrueHD and has any idea why this should occur.

Fortunately DTS-HD is far more popular than TrueHD, so this is rarely an issue. Still it would be good to get it resolved.

InflatableMouse · « **Reply #1 on:** January 16, 2013, 06:40:55 am »

I'd test it but I don't have anything with THD.

Jong · « **Reply #2 on:** January 16, 2013, 06:44:42 am »

Yeah, it's lucky that! Thanks anyway!

fitbrit · « **Reply #3 on:** January 16, 2013, 01:17:02 pm »

Yes me too, and I have mentioned this before. I have to use bitstreaming to make it work satisfactorily. It's the only sound format that I'm bitstreaming in one of my HTPCs. I think it started during one of the LAV updates in MC17. Unfortunately, it's more than just a few times in a movie.

Jong · « **Reply #4 on:** January 16, 2013, 01:34:33 pm »

Thanks, good to know I am not going mad. Did you try increasing the WASAPI buffer? I'm trying 250ms but it's too soon to say if it helps.

Hendrik · « **Reply #5 on:** January 16, 2013, 01:35:49 pm »

The only thing that makes TrueHD special is that TrueHD has extremely short blocks, and with short i mean like 0.8333ms per block. LAV will buffer a few blocks to avoid the biggest issues, and usually send 5ms samples to the audio renderer (because 5ms is the first where you get an integer number of milliseconds, which LAV prefers, 6x0.83333 = 5)

However, most other codecs have much longer blocks. DTS is typically 10.6667ms, AC3 is 32ms, so it is possible something doesn't like dealing with such short blocks. For example, a thread which does a Sleep(1) (sleep for 1ms) between processing blocks can already cause issues here.

I have never gotten any complaints otherwise, so i am somewhat inclined to blame some interaction with MC.

PS:
Bitstreaming actually has similar issues with short blocks, and because of this the bitstreaming spec says that 24 blocks (resulting in 20ms of data) should be packed up into one data packet so solve the issue. Obviously LAV does this for bitstreaming, or it wouldn't work. :p

Jong · « **Reply #6 on:** January 16, 2013, 02:12:56 pm »

Thanks nev, any chance we could have a version with a bigger block size for testing? Near the size for DTS would probably be OK, if this is the issue, because I have never seen this problem with DTS-HD.

Hendrik · « **Reply #7 on:** January 16, 2013, 02:15:15 pm »

Quote from: Jong on January 16, 2013, 02:12:56 pm

Thanks nev, any chance we could have a version with a bigger block size for testing?

Not likely, no. There is other reasons its limited to 5ms and doesn't also collect 20ms like bitstreaming, other issues start to come into the picture.

For the record, Blu-ray PCM tracks also have 5ms samples, although PCM on Blu-ray seems to be equally rare as TrueHD these days.

Jong · « **Reply #8 on:** January 16, 2013, 02:19:00 pm »

Hmm, OK. hopefully Matt has some ideas then.

Jong · « **Reply #9 on:** January 16, 2013, 02:20:53 pm »

Do you think increasing the WASAPI buffer could help here or is that completely pointless?

Matt · « **Reply #10 on:** January 16, 2013, 02:23:34 pm »

What's your JRMark (Help > Benchmark)?

Jong · « **Reply #11 on:** January 16, 2013, 02:29:10 pm »

Matt · « **Reply #12 on:** January 16, 2013, 02:36:18 pm »

It's possible the incoming block size changes things. We do a certain amount of work each time we receive data, so the receive frequency matters. It could also be a problem if we didn't receive data often enough.

This is because we piggy-back on the Receive(...) calls to push data out to the output plugins.

If there were a way for me to reproduce an issue, we might learn something. Does anyone have a sample file? Or nevcairiel, is it easy to force certain deliver sizes for debugging?

Matt · « **Reply #13 on:** January 16, 2013, 02:37:13 pm »

Quote from: Jong on January 16, 2013, 02:20:53 pm

Do you think increasing the WASAPI buffer could help here or is that completely pointless?

Can you reproduce this easily?

Is it worse if you switch to 10ms instead of 100ms, or no different?

Jong · « **Reply #14 on:** January 16, 2013, 02:47:46 pm »

I only get 2-3 drops randomly in a movie so I'm not sure yet if 250ms helps or hinders. But tomorrow I can try 10ms and see if it gets worse. Good idea.

Hendrik · « **Reply #15 on:** January 16, 2013, 02:51:11 pm »

Quote from: Matt on January 16, 2013, 02:36:18 pm

Or nevcairiel, is it easy to force certain deliver sizes for debugging?

In theory i can make it collect data to any block size, its just a define in the code. However collecting more may eventually lead to other issues, if less helps you debugging, that can easily be done.

Jong · « **Reply #16 on:** January 16, 2013, 02:51:34 pm »

Quote from: Matt on January 16, 2013, 02:36:18 pm

Does anyone have a sample file? Or nevcairiel, is it easy to force certain deliver sizes for debugging?

A sample is hard. Most recently I've had the problem with the latest Star Trek on bluray. I could encode to mkv and take a sample of that, but I've no idea if all the repackaging would change the result. I don't have a tool to chop a sample out of an m2ts. Do you know of one?

Jong · « **Reply #17 on:** January 16, 2013, 02:53:17 pm »

Quote from: nevcairiel on January 16, 2013, 02:51:11 pm

In theory i can make it collect data to any block size, its just a define in the code. However collecting more may eventually lead to other issues, if less helps you debugging, that can easily be done.

Just doubling to 10ms (from what you said close to DTS-HD) might be enough.

Happy to test with less too.

Matt · « **Reply #18 on:** January 16, 2013, 03:02:45 pm »

Quote from: nevcairiel on January 16, 2013, 02:51:11 pm

In theory i can make it collect data to any block size, its just a define in the code. However collecting more may eventually lead to other issues, if less helps you debugging, that can easily be done.

If we could easily reproduce a problem when you output the 0.86ms chunks, we could try to fix that and see if it fixes the more sporadic issue users are reporting.

I do have a TrueHD blu-ray here, so I don't think I need a sample.

Hendrik · « **Reply #19 on:** January 16, 2013, 03:09:47 pm »

This version has the buffering simply commented out, so you'll always get the true audio frame size, for TrueHD that is 40 samples, at 48000Hz that is 0.83333ms.

http://files.1f0.de/lavf/LAVFilters-0.55.1-truehd-test.zip

Thinking about it, 40 samples is really terribly short =p

fitbrit · « **Reply #20 on:** January 16, 2013, 03:29:33 pm »

Quote from: Matt on January 16, 2013, 03:02:45 pm

If we could easily reproduce a problem when you output the 0.86ms chunks, we could try to fix that and see if it fixes the more sporadic issue users are reporting.

I do have a TrueHD blu-ray here, so I don't think I need a sample.

Matt, I just tested several short clips. There's one particular file that is really bad. You can hear the difference between it being decoded in MC and the bitstreamed version. It's about 900MB in size. My point is that some files may be worse than others and your lone BD may not show this issue. Do you have a dropbox or something that you could use if I were to send you this file? Mine is almost full with work stuff.

Matt · « **Reply #21 on:** January 16, 2013, 03:31:02 pm »

Thanks for the build. It delivers 40 samples at a time, just like expected.

However, it's playing fine for me. CPU usage is low and audio is steady (even in debug where everything is much slower).

I'm not doing much DSP, but I am doing VideoClock and AC3 encoding of the output.

Are these drop-outs always at the same spot? Is it possible there's a file or decoder issue and we're actually getting silence delivered?

Any particular DSP you're using?

Any other ideas?

Matt · « **Reply #22 on:** January 16, 2013, 03:33:59 pm »

Quote from: fitbrit on January 16, 2013, 03:29:33 pm

Do you have a dropbox or something that you could use if I were to send you this file? Mine is almost full with work stuff.

I'd love a sample, but we don't have hosting we can share.

Hendrik · « **Reply #23 on:** January 16, 2013, 03:36:21 pm »

Quote from: fitbrit on January 16, 2013, 03:29:33 pm

Do you have a dropbox or something that you could use if I were to send you this file?

I should really finish my plans for a sample sharing webapp, for all the people having trouble to find an easy way to share something with the devs.

* nevcairiel gets back to the drawing board for that

I have a dropbox or google drive, but i actually have no clue if i can let someone else write stuff into my own folders? I know i can share read access.... :p

fitbrit · « **Reply #24 on:** January 16, 2013, 03:51:05 pm »

Quote from: nevcairiel on January 16, 2013, 03:36:21 pm

I should really finish my plans for a sample sharing webapp, for all the people having trouble to find an easy way to share something with the devs.
* nevcairiel gets back to the drawing board for that
I have a dropbox or google drive, but i actually have no clue if i can let someone else write stuff into my own folders? I know i can share read access.... :p

Yes you can, I believe.

Hendrik · « **Reply #25 on:** January 16, 2013, 04:00:22 pm »

Apparently shared folders are always writeable, or so the internet claims, if you let me know your dropbox account i can share a folder for upload, and then link the file here.

Jong · « **Reply #26 on:** January 16, 2013, 04:02:27 pm »

Quote from: Matt on January 16, 2013, 03:31:02 pm

Are these drop-outs always at the same spot? Is it possible there's a file or decoder issue and we're actually getting silence delivered?

in my testing the drop outs are not in the same place. First thing I tried was rewinding back a few mins and playing again and I have played the same discs several times now.

I do nothing to the sound except use Videoclock and standardise on 24-bits - same number of channels as source, no DSP.

fitbrit · « **Reply #27 on:** January 16, 2013, 04:04:16 pm »

I've created a GoogleDrive folder and shared with Matt. Send me your email addresses by PM if you want me to add you

JimH · « **Reply #28 on:** January 16, 2013, 04:04:49 pm »

Virus checker....

Matt · « **Reply #29 on:** January 16, 2013, 04:13:16 pm »

Quote from: fitbrit on January 16, 2013, 04:04:16 pm

I've created a GoogleDrive folder and shared with Matt. Send me your email addresses by PM if you want me to add you

Thanks. I requested access from you for jriver.development, and am awaiting approval.

Jong · « **Reply #30 on:** January 16, 2013, 04:14:58 pm »

The drops are so infrequent I suspect it's a bit like the problem of frame presentation before MadVR exclusive mode allowed multiple frames to be presented in advance - all is fine until some Windows service decides to go on hiatus for a few ms.

fitbrit · « **Reply #31 on:** January 17, 2013, 02:28:33 am »

File uploaded. In my system, the first few seconds are horrible when decoding but you have to listen carefully for the sound artifacts. Pure heaven when bitstreaming.

Hendrik · « **Reply #32 on:** January 17, 2013, 03:19:56 am »

Does it only happen at the start of playback, or also later on?

fitbrit · « **Reply #33 on:** January 17, 2013, 03:35:27 am »

Quote from: nevcairiel on January 17, 2013, 03:19:56 am

Does it only happen at the start of playback, or also later on?

All the way through. Seems like even the video is struggling sometimes.

Jong · « **Reply #34 on:** January 17, 2013, 07:31:07 am »

I've tried using a 10ms h/w buffer and things do not get noticeably worse, in about 45 mins testing. So at the moment I'd say changing the buffer doesn't affect this problem one way or the other.

Matt · « **Reply #35 on:** January 17, 2013, 08:04:55 am »

@fitbrit
Could you grant access to the file to the jriver dot development at gmail address? I sent a request through Google.

Thanks.

Jong · « **Reply #36 on:** January 17, 2013, 11:01:42 am »

After longer testing (in the background while working!) reducing the buffer has no negative impact. In fact I didn't notice any drops in about 80% of a movie (had to dive out a few times). Don't know if that was just a "lucky run" or if reducing the buffer somehow made things better!

fitbrit · « **Reply #37 on:** January 17, 2013, 11:29:29 am »

Quote from: Matt on January 17, 2013, 08:04:55 am

@fitbrit
Could you grant access to the file to the jriver dot development at gmail address? I sent a request through Google.

Thanks.

Matt, I did so twice last night. Will try again.

EDIT - My Google Drive says both that address and your regular one have editing privileges to the file.

Matt · « **Reply #38 on:** January 17, 2013, 11:53:06 am »

Quote from: fitbrit on January 17, 2013, 11:29:29 am

Matt, I did so twice last night. Will try again.

EDIT - My Google Drive says both that address and your regular one have editing privileges to the file.

It's working today. I'm downloading now and will follow-up later today.

Matt · « **Reply #39 on:** January 17, 2013, 01:31:19 pm »

I listened to the sample loud on headphones so nothing would be able to hide from me. Gravedigger is one of my favorite Dave Matthews songs. It sounds great!

I'm running in the debugger which is slow and also using the special LAV filter that delivers extra small blocks. I tried different buffer sizes, but none of it mattered.

Since one of the computers seeing this has a JRMark over 4000, I would be surprised if it was a performance issue.

Any ideas what we should try next?

Matt · « **Reply #40 on:** January 17, 2013, 01:33:53 pm »

What if you copy the file to a fast local drive?

I've seen cases where LAV does its I/O one byte at a time. It's possible that could cause a problem on certain NAS devices. I'm not sure if the LAV source always buffers, and only the splitter reads one byte at a time, so this is just an idea.

Jong · « **Reply #41 on:** January 17, 2013, 02:39:26 pm »

My movies are on a local drive. Ok it's 5400rpm but.....

I'll see if it's gone away with the smaller buffer size. Maybe it's an odd device driver issue?

JimH · « **Reply #42 on:** January 17, 2013, 02:47:33 pm »

Quote from: JimH on January 16, 2013, 04:04:49 pm

Virus checker....

fitbrit · « **Reply #43 on:** January 17, 2013, 03:00:39 pm »

Quote from: JimH on January 17, 2013, 02:47:33 pm

Say it one more time and I'll look into it.

(Will check when I get home, Jim.)

Jong · « **Reply #44 on:** January 17, 2013, 03:03:06 pm »

Quote from: Matt on January 17, 2013, 01:31:19 pm

Since one of the computers seeing this has a JRMark over 4000, I would be surprised if it was a performance issue.

Unless you think buffering would certainly protect from this, with such small packets it could be a combination of Windows timer resolution and occasional errant services not allowing other processes in fast enough. Certainly this is enough to occasionally trip up video presentation, without MadVR exclusive mode, and with these timings it sounds as tight, if not tighter.

mojave · « **Reply #45 on:** January 17, 2013, 03:29:48 pm »

Quote from: fitbrit on January 17, 2013, 03:00:39 pm

Say it one more time and I'll look into it.
(Will check when I get home, Jim.)

Windows Defender is built into Vista and Windows 7. Although it is antispyware it may also cause an issue.

Jong · « **Reply #46 on:** January 17, 2013, 04:14:51 pm »

If any correctly functioning, popular anti- malware product causes problems specifically with TrueHD I'd say the problem is in MC/LAV/maybe drivers due to small packet size (but hopefully addressable).

Hendrik · « **Reply #47 on:** January 17, 2013, 05:35:56 pm »

If you have the problem you can try the debug build, and if it's really the short packets the problem would be greatly amplified.

Since bitstreaming works, I would rule out the splitter for now.

@Matt: the 1-byte reading thing should be fixed, at least when there is a reliable file size (and it was only the splitter)

Matt · « **Reply #48 on:** January 17, 2013, 06:30:59 pm »

Could you guys test with VideoClock enabled and disabled. Any difference?

fitbrit · « **Reply #49 on:** January 17, 2013, 08:08:57 pm »

Quote from: Matt on January 17, 2013, 06:30:59 pm

Could you guys test with VideoClock enabled and disabled. Any difference?

Hurrah!

Bitstreaming on, VC enabled: Perfect
Bitstreaming on, VC disabled: Perfect
Bitstreaming off, VC enabled: Abomination
Bitstreaming off, VC disabled: Perfect

The weird thing is that I thought VC was off on this HTPC because the TV is fixed at 60 Hz. Thank you, Matt! Bye bye Bitstreaming. Hello JRSS 2.0 for everything!

INTERACT FORUM

Author Topic: Occasional sound drops with TrueHD/LAV (Read 20933 times)