INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: 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.
-
I'd test it but I don't have anything with THD.
-
Yeah, it's lucky that! Thanks anyway!
-
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.
-
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.
-
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
-
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.
-
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.
-
Hmm, OK. hopefully Matt has some ideas then. :)
-
Do you think increasing the WASAPI buffer could help here or is that completely pointless?
-
What's your JRMark (Help > Benchmark)?
-
4591
-
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?
-
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?
-
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.
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
-
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?
-
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.
-
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./me 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
-
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./me 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.
-
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.
-
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.
-
I've created a GoogleDrive folder and shared with Matt. Send me your email addresses by PM if you want me to add you
-
Virus checker....
-
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.
-
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.
-
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. :)
-
Does it only happen at the start of playback, or also later on?
-
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.
-
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.
-
@fitbrit
Could you grant access to the file to the jriver dot development at gmail address? I sent a request through Google.
Thanks.
-
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
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, 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.
-
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?
-
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.
-
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?
-
Virus checker....
-
Say it one more time and I'll look into it. :)
(Will check when I get home, Jim.)
-
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.
-
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.
-
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).
-
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)
-
Could you guys test with VideoClock enabled and disabled. Any difference?
-
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!
-
Bitstreaming off, VC enabled: Abomination
Well, now we're getting somewhere.
Is Windows using 60Hz for the display resolution?
Could you send me a log showing playback when it's bad?
I'll also test on my side and see if I can notice VideoClock doing anything unexpected. Maybe if it's making corrections too often (because of the small chunk size with TrueHD) it causes trouble.
-
Yes, Windows is using 60Hz.
The attached log shows playback with VC on the first time, and VC off the second time of playback.
-
BTW, I tried to reproduce the problem with the file on the local drive, and I could every time. I really think you're on the right track with VideoClock, at least on my system.
OT:
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!
Yes, this is a great song, and the BluRay is amazing all around. I use this track to demo my 15 speaker (11.2) home theatre, and it sounds jaw-droppingly good upmixed with DTS NeoX. In my other 11.1 system that only plays 9.1 at any time, the combination of JRSS upmixing to 7.1 with (medium enveloping) and then further Audessey DSX wide speaker upmixing also just wraps the listener in audio bliss. 2 channel sounds good too, but I love being surrounded. Finally, bass transducers make it feel like you're on stage with them!
-
Just FYI, the VideoClock feature is always disabled (the setting is ignored) when Bitstreaming is enabled. Right?
-
Just FYI, the VideoClock feature is always disabled (the setting is ignored) when Bitstreaming is enabled. Right?
Yes, I assumed so, but the check mark is shown regardless. Perhaps that should change? I seem to remember having to help some people either here or on AVS with that detail too.
-
Not all formats can be bitstreamed, so videoclock would still be active for those.
-
Not all formats can be bitstreamed, so videoclock would still be active for those.
Doh! Of course. I stay up way too late! :)
-
I think I may have found something.
With a DSP that works in windows enabled, we could get into a state where a little bit of input data was available but not enough to actually output anything (since the amount of input data was smaller than the DSP window size). In this case, we could incorrectly wait for the input data to empty.
So please test MC 18.0.118 or newer once it's available and let us know what you find.
Thanks.
-
Will do. Looking forward to it.
-
I think I may have found something.
With a DSP that works in windows enabled, we could get into a state where a little bit of input data was available but not enough to actually output anything (since the amount of input data was smaller than the DSP window size). In this case, we could incorrectly wait for the input data to empty.
So please test MC 18.0.118 or newer once it's available and let us know what you find.
Thanks.
In build 118, the situation with videoclock enabled is MUCH better, but still not perfect. Still some echo and popping artifacts compared to bitstreaming of the test file.
-
In build 118, the situation with videoclock enabled is MUCH better, but still not perfect. Still some echo and popping artifacts compared to bitstreaming of the test file.
Could you increase your WASAPI buffering from 10ms to 25ms?
-
Matt, I think I take back what I said before. The next two listenings seem to have been flawless. My wife is making some noise however, so I might need to take you approach and use headphones. I'll wait until she's asleep since I'm not ready to lose everything I've invested in home theatre in a divorce just yet.
-
Could you increase your WASAPI buffering from 10ms to 25ms?
25 ms is definitely flawless. :)
You also seem to have fixed the surround field issue (http://yabb.jriver.com/interact/index.php?topic=77155.0) I mentioned recently.
-
Thanks Matt looking forward to trying this tomorrow (actually later this morning. 03:30 here, been watching the Fringe finale!).
Bit harder for me with only 2 or 3 dropouts per movie, but still. :) What WASAPI settings do you recommend?
-
Thanks Matt looking forward to trying this tomorrow (actually later this morning. 03:30 here, been watching the Fringe finale!).
Bit harder for me with only 2 or 3 dropouts per movie, but still. :) What WASAPI settings do you recommend?
I hope it works for you too! Did you have video clock enabled as well?
-
Yes. I'm hopeful :)
-
Unfortunately, 20mins in I had another crackle and brief silence using .118 with event style WASAPI and 25ms buffer. Trying again with 100ms.
-
Played the rest of the movie with 100ms buffer and no drops. Not conclusive but good. Also, thinking about it, the drop this morning felt different. It was almost instantaneous. Before they have been longer - much bigger than a buffer delay - around 1 sec if not slightly more. So maybe this mornings prob was not the same as before. Just caused by too small a buffer?