![]() |
|
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 |
- 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 - 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 ![]() @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). |