AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version
+- Kodi Community Forum (http://forum.kodi.tv)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)
- Calvados - 2012-01-29 11:29
Alright - I have upgraded to latest git, and was not able to play any DTS-HD content. So I looked at the code, compared with the history, and changed back the code to:
#define PERIOD_SIZE_MS 4
#define ALSA_PERIODS 32
before that I tried ALSA_PERIODS of 8, 16... then bumped the PERIOD_SIZE from 20 to 40... which made it worse. I do get an awfull lot of "ERROR: CAESinkALSA::AddPackets - Timeout waiting for space", so I know those settings are not quite right either.
Just my two cents.
- Calvados - 2012-01-29 14:03
Played more with the code... Anything outside of 4 / 32 combination seems to fail for me. Guessing there are some HW limitations here.
Now, as far as the m_timeout is concerned, I find your code funny. I mean if you go back to what the formula means, it basically can be reduced to (PERIOD_SIZE_MS * 1.5f). I don't supposed you intended that, since I assume you wanted to wait longer if the thing is bigger . Late night coding will do that I assume .
- gnif - 2012-01-29 16:23
@Calvados - I will investigate this further tomorrow, its late now, but I am pretty sure the wait timeout calc was correct. ALSA should return once there is at-least one period to fill, 1 period is roughly 20ms depending on hardware, so 20ms * 1.5 gives some room for error in timing, but perhaps not enough.
Edit: and no its not (PERIOD_SIZE * 1.5f)
Edit 2: I have adjusted this now to (* periods) instead of 1.5, if it has to wait this long, there is something seriously wrong.
* @DDDamian has updated WASAPI again with some more patches and tweaks, the logging issue will be corrected soon, from what I understand this should only be logged in exclusive mode, but wont know until I can follow this up with him.
* AE now performs dithering when converting to 16bit, this improves the noise floor considerably, 8bit is soon to come.
* Float -> S16 conversion has been completely re-written to accommodate dithering, but also to squeeze more performance out of SSE, I have not yet profiled the new code, but I can already say it will be faster without a doubt.
* New random functions for use with dithering, these are based on an Intel whitepaper and perform anywhere between 2-5x faster then the standard rand() function. The SSE version is also designed to return a __m128 value if desired, so that it can be directly plugged into other SSE optimized code.
- DDDamian - 2012-01-29 18:20
gnif Wrote:* @DDDamian has updated WASAPI again with some more patches and tweaks, the logging issue will be corrected soon, from what I understand this should only be logged in exclusive mode, but wont know until I can follow this up with him.
Checked MutatedHeros log - got stuck in an endless loop - sink opening in RAW - back to SoftAE:OpenSink and re-open again - see the issue, patch coming. After successfully opening the sink it checks IsCompatible a second time?!? Don't know why that didn't happen for me yet, but just read log. I'll update in about 8hrs.
gnif Wrote:* AE now performs dithering when converting to 16bit, this improves the noise floor considerably, 8bit is soon to come.
That was a *&%*%ing quick port lol! For anyone interested dithering reduces quantization errors (aka distortion) in converting back to 16bit, to the theoretical equivalent of ~16-20db. Hope not too many folks are using 8bit sources, but in almost all cases except 24-bit FLAC this will improve sound quality substantially.
*** Folks - one request while you're doing your tests: please distinguish your platform when posting - maybe put [LINUX] or [Win7] etc in your post. Just makes it easier to know who has to fix. Appreciate your testing efforts! As always logs required - if you can't you shouldn't be testing. Also, given the demanding requirements of high-quality audio pls ensure your compiler's set to optimize the code!
- DDDamian - 2012-01-29 18:29
pike Wrote:Heh, my processor takes 7-10 seonds to adjust between stream changes, so (without me having read exactly what this does) I sure hope it's optional.
@Pike - on my receiver it's ~0.5 - 1.0 seconds, so the switching time's definitely equipment-dependent. Regarding options gnif's intent is to have the tweaks available in advancedsettings.xml, including the audiophile switch. I'd expect releases would have the smoothest/simplest settings as default.
I too have many SACD rips (and DVD-A) and have to use Foobar for them. There's an awesome open-source decoder in SourceForge for Foobar which can open the raw ISO's and convert DSD to PCM at multiple sample rates, and even supports tagging and replaygain metadata. Perhaps we can talk to it's developer and get SACD in AE in the future.
With regards to the upmixing and upsampling - this is gnif's baby (and what a baby!) so he'd have to address that.
I can say that in just a few conversations with him he's one heck of a smart cookie - i think his brain processes the real world in ++
- dado483 - 2012-01-29 18:39
Komet Wrote:It would be great if you could publish you merge-branch!
If you read this thread you found that my brach is already pusblished.
git clone -b AE-betaEden git://github.com/dado483/xbmc.git
- gnif - 2012-01-29 18:44
@dado483 - What is this fork, what is different about it to the official AE branch... I merge AE with whats in master periodically so it is effectively EDEN+AE already.
- Hack_kid - 2012-01-29 19:02
hey how do i enable the audiophile mode? a switch in as.xml? whats the syntak?
- DDDamian - 2012-01-29 19:16
Hack_kid Wrote:hey how do i enable the audiophile mode? a switch in as.xml? whats the syntak?
Should be on by default right now. Will be added to advancedsettings.xml in any release.
- DDDamian - 2012-01-29 19:18
gnif Wrote:@dado483 - What is this fork, what is different about it to the official AE branch... I merge AE with whats in master periodically so it is effectively EDEN+AE already.
@gnif - He's merged with PVR.
- dado483 - 2012-01-29 19:19
Calvados Wrote:Alright - I have upgraded to latest git, and was not able to play any DTS-HD content. So I looked at the code, compared with the history, and changed back the code to:
I can confirm that changing back PERIOD_SIZE_MS and ALSA_PERIODS as Calvados, DTS-HD and TrueHD bitstreaming is running again.
Using new Gnif parameters creates a lot of audio discontinuity problems and audio is not working (only for DTS-HD and TrueHD, DTS and Dolby Digital is working regulary)
- gnif - 2012-01-29 23:07
@Hack_kid - This is now disabled by default, the setting is as below to enable it
- Calvados - 2012-01-30 01:15
@gnif: The issue is not the timeout computation, I did set it back to -1 at one point with the 20/4 couple, and it was still not able to play HD. I guess I didn't emphasize enough on this in my last answer. I think it's more about a frame/buffering issue.
Now, I did check the code at the time, and saw you were reading the periodSize value, albeit after setting it. BUT in effect on my HW, whatever PERIOD_SIZE_MS is used ended up to be the delay timeout set *1.5f. So I concluded things.
- gnif - 2012-01-30 02:09
@Calvados - I have tracked down the issue, it is because I was calculating the period timeout and size assuming it was analog output, not a bitstream format. I have committed some fixes that should make things run smooth again. There are hard coded values for normal bitstreaming, and higher bitrate values for HD streams.
I have also located and fixed the looping sync re-open issue
- Calvados - 2012-01-30 03:01
@gnif - Looks like you fixed the video playback . Nice work.
Now, I do have a problem, which didn't exists before my recent upgrade (i was running a build from October), with replaying a 5.1 88Khz FLAC. IF I start with that, I get silence. IF I play a stereo FLAC, not a problem.
The multichannel replays output a lot of "ERROR: CAESinkALSA::AddPackets - Underrun". Here is the kicker though - Timeout for FLAC multichannel 31 ms, Stereo 160ms... I am guessing there is an edge case you didn't cover due to your latest fixes.
If you need the log, I can post it.