Kodi Community Forum

Full Version: [Windows] AudioEngine testers - Windows platform only
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2012-04-26, 23:01)DDDamian Wrote: [ -> ]@HeresJohnny - those are nothing to worry about, will fix

This might actually be something my receiver is doing since it provides signal passthrough when powered down or when in power save mode. I love my Yammy Smile Dunno if it could be a problem, too, since the output device seems to change, I just checked. Then again, it probably won't change while something is being processed.

(2012-04-26, 23:01)DDDamian Wrote: [ -> ]@loekf - will test the sample - glad the other two play now - was an issue with parsing the DTS in that particular format. By and large though sounds pretty good Smile

Thanks, the file is now in my Dropbox public folder
@loekf - thx

@HeresJohnny - no worries - it's just a user-friendly tag, we're just not consistent in applying the prefix or saving the one with or without additional info in the string.
I confirm what others found before me: NVIDIA ION will play neither TrueHD nor DTS-HD. By untagging the capabilities for DTS-HD XBMC tries to reproduce the DTS core, but it's choppy. Untagging TrueHD still gives no sound (should there be an AC3 core?). DTS 24/96 works nicely though, I've tried Depeche Mode and Genesis.
Not familiar with the ION, but the device enumeration now added (and enabled in log with debugging on or set to level 1) should show whether support is there or not.

Untagging DTS-MA should play DTS core, and if it's choppy we would need a sample of the file.

Untagging TrueHD will force decode to multichannel LPCM, not to AC3, maybe we can look at that for audio devices that don't support mc lpcm.

And yep, DTS 24/96 sounds great! Smile
(2012-04-26, 22:14)DDDamian Wrote: [ -> ]Alright!! Now for this buffering issue can I please get a log. And does it actually show on the screen that it's buffering?

Hi Damian and gnif,

here's the log file of dts-master playback with the buffering problem.

http://dl.dropbox.com/u/7782292/xbmc_buffering.log

I hope it helps you to get an idea what the problem is.

Thanks again for all your work,

Chris
(2012-04-26, 21:12)DDDamian Wrote: [ -> ]For anyone experiencing the DTS-MA bug - another potential cause found and fixed in this build >>DTS-MA test<<

Well... that build is made of pure awesomesauce!!
Seems to have fixed the dropouts with DTSHD-MA for me.

Thanks very very much for all the hard work! Big Grin

(2012-04-26, 21:12)DDDamian Wrote: [ -> ]For anyone experiencing the DTS-MA bug - another potential cause found and fixed in this build >>DTS-MA test<<

many thanks for this build. it works perfect with dts hd ma. and a very useful stereo upmix. this is ATM the best build for me for playing movies and tv-shows.

edit: for music i use di.fm addon and it plays aac 40 kbps. that sounds great so i deselected dts neo in my amp. and my subĀ“s are burning and i have to smile Wink

big thx
(2012-04-27, 14:24)Nimo Wrote: [ -> ]a very useful stereo upmix. this is ATM the best build for me for playing movies and tv-shows.

+1 Big Grin Best build for everything...

Well done gnif and dddamian. Wink
Well this is damn pleasing to hear Smile Sounds like that nasty bug is gone.

Out of >20,000 lines of code the fix was already pointed out by Anssi a few weeks ago, and included in the last build, just mis-converted from ffmpeg code:

Code:
-  packet->m_length    = ((size + 0x9) &~ 0x9) - 0x8;
+  packet->m_length    = ((size + 0x17) &~ 0x0f) - 0x08;

A simple hex conversion error was causing the grief, but very hard to spot in a huge list of parsing and re-packing code, and ofc it was working okay on some equipment including ours so even harder to track.

Aemstel, another diligent tester for us, has reported back that it's fixed on his setup too. Also reported perfect sync compared to all the non-AE builds out there including Daniela's, which is based on stock XBMC and ofc has the same 24p sync issues as stock XBMC. This is a pretty huge step on it's own - that issue has been a major one here in the forums. Still trying to tighten up further - the Win sync is a little laxer than Linux right now, I believe due to background Windows processing but I'm working on that.

ix400 - Aemstel's not seeing the buffering - still looking at what may be the cause there. One thing I note is that ffmpeg has a tough time with that ZZ-Top rip (and I have a rip of that without issues). There are many ffmpeg errors opening/reading it at loglevel 2. Do you have any other test material to try?
(2012-04-27, 17:15)DDDamian Wrote: [ -> ]the Win sync is a little laxer than Linux right now, I believe due to background Windows processing but I'm working on that.

Hey DDDamian,

That's what i've noticed. It's bloody close however looks slighty out still.

Cheers
(2012-04-27, 17:15)DDDamian Wrote: [ -> ]Well this is damn pleasing to hear Smile Sounds like that nasty bug is gone.

Out of >20,000 lines of code the fix was already pointed out by Anssi a few weeks ago, and included in the last build, just mis-converted from ffmpeg code:

Code:
-  packet->m_length    = ((size + 0x9) &~ 0x9) - 0x8;
+  packet->m_length    = ((size + 0x17) &~ 0x0f) - 0x08;

A simple hex conversion error was causing the grief, but very hard to spot in a huge list of parsing and re-packing code, and ofc it was working okay on some equipment including ours so even harder to track.

Aemstel, another diligent tester for us, has reported back that it's fixed on his setup too. Also reported perfect sync compared to all the non-AE builds out there including Daniela's, which is based on stock XBMC and ofc has the same 24p sync issues as stock XBMC. This is a pretty huge step on it's own - that issue has been a major one here in the forums. Still trying to tighten up further - the Win sync is a little laxer than Linux right now, I believe due to background Windows processing but I'm working on that.

ix400 - Aemstel's not seeing the buffering - still looking at what may be the cause there. One thing I note is that ffmpeg has a tough time with that ZZ-Top rip (and I have a rip of that without issues). There are many ffmpeg errors opening/reading it at loglevel 2. Do you have any other test material to try?


... I just ripped my Toto BD as a BDMV folder, without converting it to mkv. It seems to buffer even more...

A quick test with daniela's build resulted in no buffering at all.

Strange.

Chris
@ix400 - AE handles buffers very very differently to DaniellaE's build, can you provide a sample if possible thats long enough to reproduce the problem so we can see if we can figure out what needs correcting.
(2012-04-27, 19:44)gnif Wrote: [ -> ]@ix400 - AE handles buffers very very differently to DaniellaE's build, can you provide a sample if possible thats long enough to reproduce the problem so we can see if we can figure out what needs correcting.

... I could provide a sample, but I'm not sure if this helps. I testet more files now and I get the buffering problem quite often. Even sometimes with SD files with a regular DD sound track.

I made the following observations:

1. In general, it takes much longer for XBMC to open the files
2. Sometimes, after stopping and subsequent re-staring playback of a file, it works without buffering.

It feels like my unraid server doesn't have the full performance when connected to XBMC-AE. But on the other hand, I didn't change my unraid setup and I still can copy from it to the Desktop with speeds of more than 50MB/sec.

Huh

Chris
@ix400 - your log shows the sink re-opening repeatedly, there may be a bug in the code that decides if it needs to reopen or not, I doubt it is with your lan/raid speed. I have pinged Memphiz to have a look as its on the windows side of things (yeah, I am cross platform posting Tongue)