Kodi Community Forum

Full Version: AudioEngine branch - DO NOT REQUEST BINARY BUILDS
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I noticed that gnif2 copied xbmc into a seperate branch: AudioEngine branch


Anyone can tell me what's the purpose of this?
To provide an engine for the audio Smile
tslayer Wrote:To provide an engine for the audio Smile

Smile I'm curious about the details. What kind of improvements are planned for example? It the current engine not good enough?
i'm hoping this branch will lead to DRC.
Well, I can Smile

Its a new audioengine to wrap up all the different media types for mixing, samplerate conversion, format conversion, encoding, upmix, downmix, etc...

And yes, DRC is on the tables Smile very early days still, only ALSA works and paplayer is missing alot, but its getting there rather fast. Dont expect ANYTHING to work however, its VERY experimental at this point.

I AM NOT ACCEPTING ANY FEATURE REQUESTS - this is mainly a code clean-up at this point and removal of SDL_Mixer for gui sounds.
Just thought I would post an update to the progress while I am waiting for a build...

So far, SDL has been stripped out of XBMC, a new audio layer called, yes, you guessed it, "AudioEngine" has been built. This new layer is able to handle bit-perfect reproduction of audio, mixing, preloaded sounds, resampling, downmixing, post-processing filters.

What works so far:
* alsa output (NOTHING ELSE)
* dvdplayer
* gui sounds
* paplayer (90%) including x-fade for wsapi users
* visualization add-ons (the interface has not changed, add-ons are compatible)

PAPlayer's stream handing code, cross fade, and gapless mess has been re-written to take advantage of AE. PAPlayer does not re-sample anymore either as AE handles re-sampling, format conversion, channel remapping, down-mixing, making the code in the PAPlayer and dvdplayer MUCH simpler and robust.

Whats still left to do before a release:
* Make paplayer output the codec's native format, currently it converts everything to float
* Make passthrough work again
* Fix paplayer's seek
* Make the other AudioRenderers work (they will probably be re-written somewhat)
* add channel mapping support to paplayer for FLAC files (this one will make lots of people happy)

Obviously NONE of this will make it into Dharma, so don't even ask for it it is way too experimental and un-tested to release just yet.

I know there has been a-lot of stalled "new audio layer" attempts in the past, this time though we are 90% through having everything working where we can move onto new features such as up-mixing, ladspa plugins, etc. There may even be a addon interface for custom post-proc filters at some stage Smile
you mean SDL mixer, SDL for SEMs, window and event handling is still present.
Hi Gnif !

This sounds awesome.

One question just came into my mind for which problem i could not find a theoretical solution:

How can cross-fade handle bit perfect playback in case two sound has to be mixed with different sampling-rate. I think either one stream has to be resampled or both has to be upsampled to a higher bitrate.

Of course this is a bit theoretical because i think most CD material is on 44.1khz/16bit, but there are some 48khz mp3 files out there.

Thanks really much for working on such hard and complex code and yes you are making a lot of people happy with this engine.

Cheers, Alan
obviously you won't get bitperfect anything if you resample/crossfade/adjust volume/do anything. worrying about bit-perfect output with mp3 is funnai though Wink
Thanks for the correction, I did indeed mean SDL Mixer

Yes, spiff is correct here too, however we will try to match the audio devices output sample rate as best we can to the input, but when mixing gets involved, all bets are off.

Here is how the sample rate selection will work (this is not done yet), if there is no streams running, and a GUI sound tries to play, we open at a default rate of 44.1khz

When a stream starts, if is the only one, and the sample rate does not match the currently configured one, AE will re-open the audio output at the correct sample rate to match.

When another stream starts, it is not the only one, so it just gets mixed in to whatever is already open. This will only occur in the paplayer for gapless and cross-fade reasons.

If however passthrough is in use, all streams are re-sampled to 48khz, and encoded after mixing to AC3
gnif Wrote:When another stream starts, it is not the only one, so it just gets mixed in to whatever is already open. This will only occur in the paplayer for gapless and cross-fade reasons.

This sounds perfect.That's the best i could think about. This is the way we can minimalize resampling occasions.

Right now to play two streams together we had to use Alsa mixing which allows only one fixed sampling rate.

Thanks for the info. I am really waiting to try it out Smile
Another update...

* Re-open of audio device to match sample rate now implemented
* Visualizations now take float data (less format conversions)
* Lots of crash fixes
* Initial pass-through has been implemented (does not function yet & un-tested)

I have managed to remove most of the unnecessary conversions between bit-depth formats now, this means a less load on the CPU since we are working in float everywhere now. In some cases the conversion could have been as as bad as float->s16->float->s16->float->s16 for the audio, and then another float->s16->float if you add visualizations to the equation.

The worst case now is, X->float, and float->s16 for some visualizations, most though work in float too, so we are down to one conversion in most cases provided your sound card supports float output. If the audio codec returns float data, we are down to 0 conversions, which is really nice IMHO.

Whats left:
* paplayer seek/ff/rr
* paplayer stop on end of playlist
* passthrough
* transcoding to ac3

and if someone is kind enough to donate the hardware, true-hd, etc... (i only have spdif hardware).

At this rate it AE should be ready to merge into trunk fairly soon depending on my available time. In the meantime, the adventurous can give it a go, just be sure to configure with --disable-pulse as only ALSA works atm.

Again, I am not accepting ANY feature requests or bug reports
gnif Wrote:and if someone is kind enough to donate the hardware, true-hd, etc... (i only have spdif hardware).


What would you need ? I can donate an nvidia video card with hdmi lpcm out gt220, probably capable of true-hd passthrough.

If you need an AV receiver, that's pretty expensive. The best i can do is make some donation through the xbmc donation system (but of course just with a less sum). Which would be a help for you ?
This sounds great (Pardon the pun)

My main interest with XBMC is delivering audio to my dac. I am happy with the sound now, but the possibility of bit perfect is great.

Can I ask if there will be any ability of delivering hires audio in any sense of the word?

As I understand how OSX works is that the audio/midi setup sets the rate and thats that. But certain softwares can change audio output on the fly such as amarra.

But anyhow, I look forward to it and hope are skinning folk will consider more focus into the audio section as well.
garyi, I am not sure what you are asking for as I am unfamiliar with the mac system, but if you are referring to outputting at the sample rate the system expects, yes, AE is able to handle that.

alanwww1, I have sent you a PM, but to be clear to everyone...

If you have faulty (and yes, I mean faulty) HDMI equipment, such as a smashed HDMI capable TV that still turns on, or an amplifier that powers up but produces no sound as it is burnt out, etc... that would be enough, I can hack it to work with it, as long as your willing to donate it to me for the greater good.

I am not looking for a free ride, but I can not afford the equipment either, so if people want it, and can't develop it themselves, id be happy to do it if I can procure the equipment. My aim is to get XBMC's audio up to scratch so people have more reasons to use XBMC over other media centers.