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)



- ashlar - 2011-04-12

gnif Wrote:I have removed the setting apply delay again, this was more of a hack to try to work around a race condition I could not find, this bug was corrected about 20 minutes ago Smile.
Maybe I'm misunderstanding, but the "apply delay" setting could be handy for people without complex AVRs.


- spiff - 2011-04-12

you misunderstood. there was a sleep() in the code to avoid updating settings too fast. nothing to do with av delay.


- ashlar - 2011-04-12

spiff Wrote:you misunderstood. there was a sleep() in the code to avoid updating settings too fast. nothing to do with av delay.
Ok, ok, I'm outta here. Sorry, delete everything. I'm no coder, I need to shut up. Sorry.


- gnif - 2011-04-12

Singing off for tonight with another update

I have fixed numerous issues with selection of HDMI output for LPCM and a crash when using HDMI and channel layout is anything other then 2.0.

Also I have begun on the TrueHD bitstream support, I can now identify the stream and detect the sample rate, still to decode the frame size, it seems that TrueHD (& MLP) have a horrid stream format that is going to be a pain to figure out, thankfully ffmpeg has some code I can use as a reference here, but its still not going to be as simple as AC3 & DTS was.

Once the frame size can be decoded it can be packed and sent to the receiver, and in theory it should work. It seems that all bit streaming TrueHD support I can find on the net is for the MS API which handles most of this, I could be wrong however.


- MutatedHero - 2011-04-12

Thanks for the update gnif, keep up the good work! Smile


- liquidskin76 - 2011-04-12

gnif Wrote:Also I have begun on the TrueHD bitstream support, I can now identify the stream and detect the sample rate, still to decode the frame size, it seems that TrueHD (& MLP) have a horrid stream format that is going to be a pain to figure out, thankfully ffmpeg has some code I can use as a reference here, but its still not going to be as simple as AC3 & DTS was.

Once the frame size can be decoded it can be packed and sent to the receiver, and in theory it should work. It seems that all bit streaming TrueHD support I can find on the net is for the MS API which handles most of this, I could be wrong however.

Excellent! Wink


- Maxoo - 2011-04-12

gnif Wrote:Also I have begun on the TrueHD bitstream support
That's a great news !!!
Thanks for keeping us updated Wink


TrueHD & Samplerate - nicob - 2011-04-13

Gniff, I really love what you are doing! And I understand that it is only initial code, but why only a sample rate of 44,1 or 48 khz for TrueHD? As TrueHD can support up to 192Khz...

Keep up the great work...


- lloydsmart - 2011-04-13

Keep up the great work Gnif, there are lots of people looking forward to this! Well done!


- gnif - 2011-04-14

@nicob: there is not a limit, its just incomplete. And if your referring to the values 44100 & 48000 in the parser code, you might note it is a base value, and shifted left depending on the bits in the stream, so 48000 << 1 = 96000, etc.


- joethefox - 2011-04-14

I follow with great interest from some time and I'm always more convinced that when will be ready, the new audio engine will be a small revolution: with the right hardware, an HTPC with XBMC will have nothing to envy of any commercial dedicated device.
Just one wish if possible: when new audio engine will be merged, how a normal user will realize that a new brand engine is here, apart of new features? An 1/20 second of volume fadeout when music stop can be a nice feedback that something of professional has happened? Big Grin

Five years old wish: http://trac.xbmc.org/ticket/2819


- nicob - 2011-04-14

gnif Wrote:@nicob: there is not a limit, its just incomplete. And if your referring to the values 44100 & 48000 in the parser code, you might note it is a base value, and shifted left depending on the bits in the stream, so 48000 << 1 = 96000, etc.
Thanks!

Before commenting I should have learned some C syntax basics...


- gnif - 2011-04-18

Another update...

This weekend I sat down and figured out the TrueHD stream format by writing a test application to experiment with. I can now parse the TrueHD stream and verify all the parity check nibbles, and the checksum on the major audio units! This is a big step towards TrueHD support, now I am to just implement the packer as TrueHD has to be packed into an undocumented (assumed) Dolby format known as MAT (Metadata-enhanced Audio Transport), which almost nothing is known about.

I have already added the new parse code to AE, but it needs some debugging as it is causing a crash at the moment, so dont update just yet and expect to get TrueHD.


- gnif - 2011-04-18

Yay, first time I have had another update before people replied to the thread Tongue

Anyway, here is the update.... its a good one.... here it comes...

Shocked TrueHD passthrough *should* be working, I cant test it yet as I don't have access to my receiver at the moment.


- Cranial - 2011-04-18

Excellent work gnif. Might have to do a build and find something to test it with....