AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version
+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133
- Clumsy - 2012-01-24 18:36
@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 21:17
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 04:35
@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. 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.
- stevos - 2012-01-25 11:52
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
- gnif - 2012-01-26 09:53
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 18:15
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 18:32
Thx for going event-driven and posting an update at 5:30am your time
- ArtVandelae - 2012-01-26 19:21
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 19:52
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 02:44
* 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.