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
- DDDamian - 2012-01-23 10:08
I found that part of the problem with not being able to open the sink in Exclusive was incomplete data in the wfxex wave_format_extensible structure. It was another reason to pass it in OpenSink.
I'll re-read through it in light of the prefer_seemless flag and see if I can pull the data from the stream then in the sink code to keep SoftAE unmodified but still correctly populate the wfxex structure reliably.
This is using an ATI card for HDMI out, and I found that RealTek vs ATI drivers made a difference in what they tolerated for initialization or changes to the stream without needing to re-open the sink.
The iteration loop is working fine for the high-order to low-order formats.
I've got the Exclusive mode issue sorted - biggest issue now appears to be buffering with DTS-HD.
- gnif - 2012-01-23 10:11
Sounds good, if you need help tracking that one down, I am pretty sure it was alanwww1 that wrote the original WASAPI and DirectShow sinks, I am sure he can assist. I would suspect the problem lies in the buffer sizes being passed back from the sink in AEAudioFormat.
- oo_void - 2012-01-23 20:32
Sorry for the noise, but I just got this branch compiled and running over the weekend. Just wanted to say, thanks for all your effort gnif and looking forward to seeing this make it into Frodo.
- wingrunr21 - 2012-01-24 00:02
Per my post here, I finally got around to investigating. It looks like something in DllAvCore.h is failing to properly detect the external FFmpeg on my Gentoo system (Gentoo compiles with an external FFmpeg by default). I am able to successfully compile with the internal FFmpeg. I will investigate further.
- gnif - 2012-01-24 05:19
@wingrunr21 - Your local ffmpeg version is too old, that's why we have an internal version as most distros are running old versions of ffmpeg. Also if I recall correctly the internal ffmpeg has a few patches to fix some issues with streams that have not yet been accepted upstream.
- gnif - 2012-01-24 06:00
Another quick update
Fixed the encoded channel count detection for AC3 and DTS in pass through mode, it may correct some of the stuttering issues people are having with DTS-HD.
DTS-HD is hard-coded to DTS core channels + 2 for now until I can figure out how to determine how many extra channels are in a DTS-HD stream, this should be fine for the majority of things and can't be any worse then the original hard coded 2.
TrueHD is still hard-coded and needs to be fixed still
- DDDamian - 2012-01-24 06:59
gnif Wrote:Another quick update
Brilliant - confirm on my rig that made a huge difference on DTS-HD. Have another drink and TrueHD will be done in minutes lol. TrueHD just locks up here - all wave_format_extensible data good, buffer fills but just stops dead.
FYI - reverted out my changes to SoftAE - all work now solely in platform-specific sink. Was going crazy trying to figure out the stutter in DTS-HD...
- DDDamian - 2012-01-24 07:08
Log analysis - prior to your last commit log on playback of DTS-HD was full of discontinuities and some buffer underruns. Now clear as a whistle on playback in log.
Issue when trying to play TrueHD:
- gnif - 2012-01-24 07:22
Great to hear it fixed DTS-HD!
can you get a stacktrace of the TrueHD crash?
- DDDamian - 2012-01-24 07:39
Will do. Two other issues since yesterday:
1) Playing a standard 1500kbps DTS movie causes the ASSERT to fail in Line 71 of SoftAEStream with m_initChannelLayout.(Count)
2) Something really odd - maybe from the new slave stream? When playing any music source the sound is static-ey until I go to fullscreen i.e. player window. Then it suddenly snaps crystal-clear. The higher the bitrate the more static, but in each case as soon as I go fullscreen its perfect again. Just happening today since I got your latest commits.