Kodi Community Forum
AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)



- stevos - 2012-01-24

jason28 Wrote:Its going to be in the next version of XBMC, they are not going to be adding it to Eden.

Thanks. A bit of a shame, as i doubt that will be out this year based on the time taken for Eden.


- fincheresque - 2012-01-24

gnif et all, let's say I have a video that plays fine in Dharma/Eden (or even in AE with bitstreaming turned off), but causes a segfault in AE (Ubuntu). Do you care? Do you want to know? I know you don't want a 'this won't play this random codec I found on the interwebs' type problem, but something that specifically can be reproduced in AE.

The majority of the videos I've been playing with are DTS-HD/TrueHD BD Rips... so if there's something I can to to help (you know, because I can't code worth a damn), I'd be happy to try.


- gnif - 2012-01-24

@nathanjones - Yes, a stack trace of crashes during pass through would be very helpful at the moment. If you can provide a sample too that consistently crashes it, even better! Please be sure however you get the latest version as a few crash issues were just fixed.


- DDDamian - 2012-01-24

@gnif - Pulled, up to date. Since your latest commits:
1. TrueHD no longer crashes a thread as described in previous post. However no sound. This is likely on the sink end. Opening sink with what should be correct parameters (and identical to DTS-HD) but won't open. Doesn't like GUID for DolbyMLP? Log attached - added lots of comments. Check near line 647 onwards for TrueHD (fail) and line 1120 onwards for DTS-HD (working).

2. No change in strange issue with garbled audio unless in player mode.

Off to do some work after 3hrs sleep - can resume testing in a few hours lol
http://pastebin.com/WvxXLCrS


- fincheresque - 2012-01-24

@gnif, thanks. I'll see what I can do. (first step: google stack trace! I know what it is, but haven't ever grabbed/done one)

No worries about using the newest commits... I check for updates (probably too) often.


- Clumsy - 2012-01-24

@nathanjones: if you have gdb installed, the xbmc log should contain a stack trace. Also see: http://wiki.xbmc.org/index.php?title=HOW-TO:Submit_a_proper_bug_report .
If you don't, one way to install it would be a "sudo apt-get install gdb".


- Hack_kid - 2012-01-24

stevos Wrote:Thanks. A bit of a shame, as i doubt that will be out this year based on the time taken for Eden.

Ever heard of nightlies


- fincheresque - 2012-01-25

@Clumsy, thanks, I've submitted logs before, but I didn't realize a stack trace was that easy. Figured there must be more to it.

@gnif, I had a chance to try out the latest commits, and I couldn't get it to segfault. Smile So whatever you did in the last commit made a heck of a difference for me.

One other thing though I was curious about, and I'm not sure if this is a known issue or not.

The DTS Capable Receiver, and DTS-HD Capable receiver options in Setup -> System -> Audio Output don't seem to be exclusive.

What I mean is, if I UNcheck DTS Capable Receiver, and CHECK DTS-HD Capable receiver, XBMC decodes both DTS files, as well as the core of DTS-HD tracks (when it should bitstream the DTS-HD one).

Now, in real life, this wouldn't be an issue, because if your receiver can decode DTS-HD, it can decode DTS, but I have some movies that stutter on DTS bitstreaming, so that would be a workaround for me.

Here's a debug log of one of the items that stutter in AE, but not in Eden. Don't know if it will help at all.

http://pastebin.com/8wqM3tCx


- stevos - 2012-01-25

Hack_kid Wrote:Ever heard of nightlies

Good point, although Eden needs to come out before Frodo nightlies will start.

I will see if i can put together a build, so at least i can help you bug test it Smile


- gnif - 2012-01-26

If your having build issues, OPEN A NEW THREAD, this is NOT SUPPORTED CODE, from now on, off topic posts WILL BE DELETED.

@aprindle - Just for the record, this problem has been corrected, the windows build should now work.


- gnif - 2012-01-26

Update:

I have finally setup a W7 system with VC++ to try to track down some of these issues under windows. Already I have identified some fairly big flaws in the WASAPI sink and have corrected them. Seems that the output is much better now and it has reduced the CPU load somewhat as we are now using WASAPI events to determine when new data is required by the device.

I have also reviewed the locks that are imposed upon the sink by CSoftAE, since nothing ever calls the sink directly for details other then the main AE thread, all synchronisation locking logic can be removed from the sinks, this should improve performance across all systems.


- DDDamian - 2012-01-26

Thx for going event-driven Cool and posting an update at 5:30am your time Laugh


- ArtVandelae - 2012-01-26

gnif Wrote:Update:
I have finally setup a W7 system with VC++ to try to track down some of these issues under windows. Already I have identified some fairly big flaws in the WASAPI sink and have corrected them. Seems that the output is much better now and it has reduced the CPU load somewhat as we are now using WASAPI events to determine when new data is required by the device.

Be careful with the event driven system. I don't know if it was a driver or Windows related bug, but I tried going that route when I initially wrote the sink and it wasn't double buffering correctly. Rather, it waited until the buffer was completely empty before triggering the refill event which caused choppy playback. Even Microsoft's own example code exhibited this behavior on my system.


- gnif - 2012-01-26

Quote:Be careful with the event driven system. I don't know if it was a driver or Windows related bug, but I tried going that route when I initially wrote the sink and it wasn't double buffering correctly. Rather, it waited until the buffer was completely empty before triggering the refill event which caused choppy playback. Even Microsoft's own example code exhibited this behavior on my system.

Events here seem to trigger fine, but it did take quite a bit of fiddle to figure out why it was only firing when the buffer was empty. You have to be sure the buffer is full before you start waiting on the event and you get events for the odd 30-50 frames as they are required. From what I can tell this is part of the MS engine and is not the drivers responsibility.

Really though at some point later, after looking at WASAPI I believe a complete AE engine should be written for it instead of a sink.


- gnif - 2012-01-27

Update:

* Fixed some more WASAPI issues with event processing.
* Fixed a deadlock on seek when the audio is being re-sampled.
* Fixed an issue with new streams being initially created paused since the new pause logic was written.
* Changed SoftAE to use a vecor of streams instead of a linked list as it helps branch prediction as well as keeping the list in the CPU cache as the memory is contiguous.

Playback in analog under windows seems to be perfect now for me, I cant test pass-through however as my windows box does not have HDMI capability.