[Windows] AudioEngine testers - Windows platform only

(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!

(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

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 Best build for everything...

Well done gnif and dddamian.

Well this is damn pleasing to hear 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:


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 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.



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 )