[P-I H]

I can confirm that the dropouts only happens when playing DTS-MA/TrueHD media.

[-JK-]

@JK - did some checking and I guess I assumed from your log and my copy of Beck - Sea Change that this was a multichannel FLAC and was being decoded as stereo which would have been a huge bug lol.

But that may not be the case. Can you describe exactly what is wrong/happening when you play those files? And just to rule it out are they multichannel or stereo?

With that same build and <audiophile> enabled all my hi-def stuff is playing back correctly.

Hi there! Actually it's the stereo version from HDtracks in 24bit and 88.2kHz. The Justice tracks are stereo as well and from the 24bit/96kHz web release. Both slightly stutter, it sounds like a major jitter issue but I have no idea what the matter really is or how to find out what's happening. Do you?

[DDDamian]

Hi there! Actually it's the stereo version from HDtracks in 24bit and 88.2kHz. The Justice tracks are stereo as well and from the 24bit/96kHz web release. Both slightly stutter, it sounds like a major jitter issue but I have no idea what the matter really is or how to find out what's happening. Do you?

I'll find out I'll take another look at the log. They play great on my rig right up to 5.1 24/192khz, but maybe I can find something in the log. Have you done anything in advancedsettings or is everything zero'd?

[-JK-]

I'll find out I'll take another look at the log. They play great on my rig right up to 5.1 24/192khz, but maybe I can find something in the log. Have you done anything in advancedsettings or is everything zero'd?

Except for the audiophile tag everything's zeroed!

[DDDamian]

I can confirm that the dropouts only happens when playing DTS-MA/TrueHD media.

Excellent - thanks. If anyone does see audio dropouts in non-BD formats please let us know.

Hi there! Actually it's the stereo version from HDtracks in 24bit and 88.2kHz. The Justice tracks are stereo as well and from the 24bit/96kHz web release. Both slightly stutter, it sounds like a major jitter issue but I have no idea what the matter really is or how to find out what's happening. Do you?

JK - I think we found the issue: Windows-only, WASAPI buffer may not be completely filled, could lead to audible skips/stutters. Good catch!

Great work so far guys - thats a few bugs found. I plan to upload the next build around the start of next week which will hopefully address all the issues found so far. Hoping to do a once-per-week upload with any bugs corrected. I'll post a notice here and in the first post of the thread. We're trying to get this merged within a few days of Eden stable release, so your help is invaluable.

Any new issues keep 'em coming!

[HeresJohnny]

In foobar2000, there's a similar issue with WASAPI buffer, maybe it helps you guys as well: In my experience 440ms buffer is the maximum that works with HD audio, possibly 390ms works best.

[DDDamian]

In foobar2000, there's a similar issue with WASAPI buffer, maybe it helps you guys as well: In my experience 440ms buffer is the maximum that works with HD audio, possible 390ms works best.

Hi there - yeah, counterintuitive, but I've noticed in Foobar the higher the bitrate the smaller the buffer has to be - I use 220msec!

In post #2 I list the current advancedsettings tags specific to AE so far - for the WASAPI exclusive mode buffer the minimum I've allowed is 50msec, but feel free to test other values. The default for exclusive is 120msec unless you set it differently in AS, but if you put less than 50msec it will be set to 50msec regardless.

Thx for the feedback, and hope someone can test some values.

[-JK-]

JK - I think we found the issue: Windows-only, WASAPI buffer may not be completely filled, could lead to audible skips/stutters. Good catch!

Great to hear, looking forward to testing the new build! :-)

[liquidskin76]

Hey dddamian,

I might have jumped the gun however i built and tested your latest commits however truehd/dts-hd vids are playing too fast. I didn't have time to grab a debug log, however can test again tonight and get the log if you need it.

Cheers!

[DDDamian]

Hey dddamian,

I might have jumped the gun however i built and tested your latest commits however truehd/dts-hd vids are playing too fast. I didn't have time to grab a debug log, however can test again tonight and get the log if you need it.

Cheers!

You're too quick there's a bunch to be merged. Will post here when there's a new working build posted - likely tomorrow or Wednesday. Often commits are done knowing there's an unrelated or unfinished side-effect, so rolling-your-own is not always safe

Glad you're eager though - me too!

[liquidskin76]

Ha... knew i had jump the gun! Cheers

[DDDamian]

Ha... knew i had jump the gun! Cheers

Such is progress I'm afraid

[DDDamian]

Just an update guys - some things broken now in the main AE repo as the code has been reworked to better seperate passthrough from non-passthrough stream handling, so holding off on posting an updated build until corrected.

[liquidskin76]

Cool. Noticed that so guessed that was the case.

Cheers for the update.

[two_OH_five]

Skipping back a couple of pages you said that truehd dropout was sort of a known problem on slow hardware

What do you class as slow?
I downloaded the latest rev from the first post link and I have dropouts on material that runs fine on Daniella's frankenEngine platform

My hw is i3-2105 with an ATI6570 GPU....not what I'd call slow but not a code crunching quad core monster

A brief look at the debug log didn't show anything with an error tag and I'm away from home now so can't easily post it. This is more of a will this info be helpful type query


Apart from this everything went well, mucho kudos to all for getting it this far