XBMC Community Forum
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)



- jayhawk785 - 2011-07-13 02:07

furii Wrote:check git, he merged master an hour or so ago.

cant seem to build today...

Quote:Error 77 error C2660: 'CGUIAudioManager::Initialize' : function does not take 1 arguments g:\xbmc\xbmc\guilib\audiocontext.cpp 184 1 XBMC
Error 78 error C2660: 'CGUIAudioManager::DeInitialize' : function does not take 1 arguments g:\xbmc\xbmc\guilib\audiocontext.cpp 197 1 XBMC
Error 79 error C2039: 'm_nVolumeLevel' : is not a member of 'CSettings' g:\xbmc\xbmc\guilib\guisound.cpp 184 1 XBMC
Error 85 error C2555: 'CDVDAudioCodecPassthroughFFmpeg::GetChannelMap': overriding virtual function return type differs and is not covariant from 'CDVDAudioCodec::GetChannelMap' g:\xbmc\xbmc\cores\dvdplayer\dvdcodecs\audio\dvdaudiocodecpassthroughffmpeg.h 111 1 XBMC
Error 86 error C2065: 'PCM_FRONT_LEFT' : undeclared identifier g:\xbmc\xbmc\cores\dvdplayer\dvdcodecs\audio\dvdaudiocodecpassthroughffmpeg.h 47 1 XBMC
Error 87 error C2065: 'PCM_FRONT_RIGHT' : undeclared identifier g:\xbmc\xbmc\cores\dvdplayer\dvdcodecs\audio\dvdaudiocodecpassthroughffmpeg.h 47 1 XBMC
Error 88 error C2039: 'GetBitsPerSample' : is not a member of 'CDVDAudioCodec' g:\xbmc\xbmc\cores\dvdplayer\dvdcodecs\audio\dvdaudiocodecpassthroughffmpeg.cpp 465 1 XBMC
Error 89 error C2664: 'IDVDAudioEncoder::Initialize' : cannot convert parameter 2 from 'AEChLayout' to 'PCMChannels *' g:\xbmc\xbmc\cores\dvdplayer\dvdcodecs\audio\dvdaudiocodecpassthroughffmpeg.cpp 465 1 XBMC
Error 125 error C2039: 'm_nVolumeLevel' : is not a member of 'CSettings' g:\xbmc\xbmc\cores\audiorenderers\win32directsound.cpp 117 1 XBMC
Error 126 error C2039: 'm_nVolumeLevel' : is not a member of 'CSettings' g:\xbmc\xbmc\cores\audiorenderers\win32directsound.cpp 209 1 XBMC
Error 128 error C2039: 'm_nVolumeLevel' : is not a member of 'CSettings' g:\xbmc\xbmc\cores\audiorenderers\win32wasapi.cpp 144 1 XBMC



- gnif - 2011-07-13 02:15

@jayhawk785 - The code went through some clean-up and the windows build has not yet been corrected for it, and thanks for the props Smile

@blub3k - I do not have a mac, and so I have no understanding at all of the OSX code, gimli is the guy who is working on that part and I believe he is doing so in a separate fork of AE.


- einhänder - 2011-07-13 11:17

seems like the ae branch still depends on -lwavpack. is that your intention?
i'm just asking because the master brach dropped the wavpack requirement as a dep, afaik.


- gnif - 2011-07-13 11:38

@einhänder - no, wavpack is not required and should have been dropped when I merged with master.


- einhänder - 2011-07-13 15:04

ah, sorry for the noise, gnif.
i forgot to specify the branch and fetched master instead of AE...

another question:
does ae work with external ffmpeg enabled? if yes is there a recommendation for a specific version of ffmpeg?


- gnif - 2011-07-14 07:33

einhänder - I have not tested external ffmpeg with AE, but it should work with any recent version as the DTS-HD and TrueHD processing code is built into AE and does not rely on ffmpeg.


- T800 - 2011-07-14 11:55

@gnif
I'm quite curious on how the new engine is created.
Is it done from documentation based on the audio codecs and then you code to suit? Is some of it guess work and then you tweak it?


- gnif - 2011-07-14 12:19

@T800 - The old code just talked directly to the audio API of the operating system, the players had to perform any conversions required to get the audio out, which meant lots of code duplication, 16bit audio, and many output inconsistencies, and no multiple stream output (eg, guisound + dvdplayer).

The Engine is an abstraction-layer which performs all the required conversions, stream mixing, resampling, etc, required to get high quality consistent output.

All the codecs now pass their raw decoded data to the streams which AE processes before passing it into the sound API and visualisation output too.

It gets even more complicated when it comes to bitstreaming as AE can operate in three modes, analog, transcode or raw passthrough.

* Analog is just that, analog.

* Transcode is when AE transparently encodes multichannel analog audio into AC3 5.1 and passes it out the sound device after encapsulating it for AC3 SPDIF.

* Raw Passthrough is where AE just passes the digital stream straight out the sound device after encapsulating it according to the format.

For example, the stream could be any one of the following

Analog:
44110hz 5.1 stream -> AE -> 44110hz 5.1 analog output (1 to 1)
44110hz 5.1 stream -> AE -> 48000hz 5.1 analog output (resampled)
44110hz 5.1 stream -> AE -> 44100hz 4.0 analog output (downmixed)
44110hz 5.1 stream -> AE -> 48100hz 4.0 analog output (resampled & downmixed)

Passthrough:
44110hz DTS-HD -> AE -> DTS -> Packetizer -> SPDIF
44110hz DTS-HD -> AE -> DTS-HD -> Packetizer -> HDMI
44110hz DTS -> AE -> DTS -> Packetizer -> HDMI
(repeat for each passthrough format, AC3, TrueHD, AAC)

Transcode:
44110hz 5.1 stream -> AE -> 44110hz 5.1 analog -> AC3Encode -> Packetizer
44110hz 5.1 stream -> AE -> 48000hz 5.1 analog -> AC3Encode -> Packetizer
44110hz 5.1 stream -> AE -> 44100hz 4.0 analog -> AC3Encode -> Packetizer
44110hz 5.1 stream -> AE -> 48100hz 4.0 analog -> AC3Encode -> Packetizer

Note that this does not take into account resolution conversion, channel remapping, or stream mixing.

In total there would have to be at least over a hundred possible input/output combinations depending on hardware, input source, user preferences, channel counts, channel mapping, sample rates.

None of this is guess work, just lots and lots of headaches.

AE's goal is to hide all this from the developer and provide a simple API that works on every platform for any random crap it is handed in the fastest and best possible way, leaving the developer to concentrate on the program rather then the issues of audio format wrangling.


- SpectreX - 2011-07-14 12:57

The sad thing is the gnif is working all by himself on some serious hardcore coding and mathematical algortims to put XBMC in same league in terms of audio with the other solutions like ffdshow, yet the rest of the developers are working on pseudo-useless features like dirty regions, to give a speed bump on an application that is already the fastest in the HTPC realm. Thanks again gnif for all the hard work


- T800 - 2011-07-14 14:30

Thanks the explanation, it sounds pretty complicated.
It is surprising for such a platform to have just one developer doing all of it. Not that it matters but at least you will have sole credit.

I'm not sure it will help at all but I've got an old Mac Powerbook I could donate to maybe help on the OSX side it (if the PPC computer is of any use).