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)



- DDDamian - 2012-01-23

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

Smile 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

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

gnif,

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

@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

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

gnif Wrote: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

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

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:
Code:
23:54:47 T:4552   DEBUG: CDVDPlayerAudio:: synctype set to 0: clock feedback
23:54:47 T:6292   DEBUG: CSoftAEStream::GetFrame - Underrun
23:54:47 T:4552   ERROR: CThread::staticThread : Access violation at 0x015414e7: Reading location 0x0a777000
23:54:47 T:4552  NOTICE: thread end: CDVDPlayerAudio::OnExit()
23:54:47 T:4552   DEBUG: Thread CDVDPlayerAudio 4552 terminating
23:54:48 T:6360   DEBUG: CDVDPlayerVideo - CDVDMsg::GENERAL_RESYNC(126000.000000, 0)
23:54:48 T:6360   ERROR: ffmpeg[18D8]: [h264] mmco: unref short failure



- gnif - 2012-01-24

Great to hear it fixed DTS-HD!

can you get a stacktrace of the TrueHD crash?


- DDDamian - 2012-01-24

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.


- DDDamian - 2012-01-24

Having a debug issue with it throwing an abort - may have to wait on the stack trace till I can clear that - it's during startup loading nothing to do with AE, more likely my environment setup.....


- gnif - 2012-01-24

DDDamian Wrote: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.

1) Need a stack trace on this one, it asserts there because the stream was created without a channel layout, should never happen.

2) Very odd indeed, I have not seen this behaviour, the slave code would most certainly not have caused any problem such as this, sounds more like memory somewhere is getting smashed.


- gnif - 2012-01-24

More Updates

* Fixed a few uninitialized variable bugs causing crashing with pass through streams (valgrind is a great tool!)
* Channel count is now correctly parsed from TrueHD streams.


- stevos - 2012-01-24

I know this is a dev forum but i am sure a lot of people are wondering the same thing

With this now being part of the main build, are we likely to be seeing AE within the next beta of XBMC or are there still a lot of issues to iron out before it can make it to a beta?


- jason28 - 2012-01-24

stevos Wrote:I know this is a dev forum but i am sure a lot of people are wondering the same thing

With this now being part of the main build, are we likely to be seeing AE within the next beta of XBMC or are there still a lot of issues to iron out before it can make it to a beta?

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