Kodi Community Forum

Full Version: Audio engine bug?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
First, I'm very impressed with XBMC's wide feature list, codec support and nice GUI. Thank you for the creators/developers who made this fantastic, almost perfect HTPC frontend possible.

As a serious hifi fan and HTPC user, I'd like to express my concerns about XBMC's audio engine. In my opinion, high quality audio (and video) playback is the single most important aspect of any mediaplayer system, be it a hardware gadget or a HTPC, that is not destined to be a shophisticated toy in the long term.

Now, in terms of audio: 1) A bit-accurate signal path from the codec output to the audio interface input is essential in the first place. 2) High quality codecs are also neccesary. 3) Sophisticated signal processing (volume control, sample rate conversion, replay gain analysis etc.) is welcomed, though external A/V receivers mostly have all the features that are needed and they implement usually state-of-the-art.

XBMC (at least OS X and Windows ports) badly lacks the first ingredient, more or less has the second, and who knows about the third. Specifically, on OS X XBMC (Babylon) has an effective 14 bit output resolution, on Windows the case is even worse (zero gain output setting is not even possible, as far as I can tell).

I wanted to check XBMC's FLAC playback capabilities, hooked up my Mac's SPDIF optical output to a DAW with an RME studio soundcard and played a FLAC file in XBMC. All volume controls set to 0 dB, SPDIF output configured to 24 bit/44.1 kHz, Replay Gain turned off. Then I compared the recorded output bit-by-bit to the original wav, and made the difference of the two. The difference wav file contains noise @-90 dB, the two least significant bits of XBMC's output is, unfortunately, purely noise.

The culprit is not the FLAC decoder as wav playback gives the same results. Core Audio is also flawless, I confirmed the with another software player ('Play') with the same file, with the same Core Audio settings and output - result was bit-accurate.

There must be some hidden processing in XBMC's audio chain that is not supposed to be there. Does anybody have an idea what is that?

The second problem is that XBMC for Mac always produces 16 bit (SPDIF) output, although the mp3 decoder has 24 bit output, and Core Audio is set to 24 bit output. How can that be? Interesting that XBMC for Windows in contrast always produces 24 bit output, although CD sources have only 16 bit wordlength.

Thanks a lot
How nice would it be if XBMC had a modular audio (and video) engine capable of using external codecs, and all post-processing would be implemented as 'plug-ins' (AU plug-ins in OS X e.g.)... Smile
adintha; it reflects exactly the number of patches you have submitted
Perhaps you should search the existing threads to understand that XBMC for Mac currently uses portaudio for audio playback and is thus limited to only what is available through the portaudio API. More searching would lead you to understand that XBMC dev DO understand the limitations of portaudio and are working on a direct coreaudio replacement. Said replacement is already branched and is known as osx-coreaudio.

You are welcome to checkout and build the osx-coreaudio branch to provide feedback if you wish.
This shows you are not that read up on XBMC

1), Just hasn't been enabled on os x, due to the audio renderer (port audio) not working properly with this.

2) Flac codecs are reference codecs.

3) Is disabled on Passthrough we don't touch the audio at all then, it doesn't do anything. If you have volume on max and without passtrhough I'm pretty sure it don't touch the audio a single bit.

EDIT: argh, missed other posters Big Grin
Just checked through code, yup 16 bit looks to be limit. It's a bug afaik and I'd say you search trac for tickets, or create a new one about this.

Preferably adding samples (from mplayer.hq or your own samples)

Cheers,
Tobias
Ok, I see, so portaudio is the problem.

Quote:adintha; it reflects exactly the number of patches you have submitted
I don't know if I exactly understand what you mean, Spiff, but the thing is that I'm not a programmer, just a user with some professional audio background, so all I can do is making comments/suggestions from this standpoint. I was just a bit dissapointed that XBMC is not yet up to the task of quality audio reproduction Sad

Quote:You are welcome to checkout and build the osx-coreaudio branch to provide feedback if you wish.
I'll look into this, thanks, Davilla.

Topfs2, I think I have to clarify some things. I know that the Flac codec is the reference code, it's OK; I just referred to the AAC codec in my first post, it give quite poor audio quality (the author also admits that). Audio passthrough is another thing, it's bit-accurate I hope, but I don't listen to music with passthrough.

If you have volume on max without passthrough, XBMC WILL touch the audio, and I don't understand why. It should not. I think this is the portaudio limitation davilla is talking about.

Quote:Just checked through code, yup 16 bit looks to be limit. It's a bug afaik and I'd say you search trac for tickets, or create a new one about this.

Preferably adding samples (from mplayer.hq or your own samples)
Thanks for the confirmationSmile. I think it's no use to bother with this until coreaudio is working.
'fatally flawed' doesn't exactly get you started on the good side of things, that was my point.
Sorry, it's not meant to be an offense to the developers. I really appreciate your work, keep it up ;-)
XBMC will only touch the audio as it is now because:

1. We want to do volume control (replaygain in particular).
2. In order to drop back to what the audio output device wants (eg 16bit for portaudio on OS X).

phi is working on a new "masteraudio" branch, in addition to the "osx-coreaudio" branch which should sort all these issues out - allowing a much better audio chain from start to finish.

Cheers,
Jonathan
Good to hear thatSmile Will "much better audio chain from start to finish" mean a bit-accurate ouput if one turns off replaygain and volume is at 0 dB? If I can find out how to integrate the masteraudio and osx-coreaudio branches, what shall I expect at this stage?

ThanksSmile
From the masteraudio branch: Nothing. It's still in the planning/initial implementation stages, but yes, the concept of not touching the audio if it's not needed (i.e. bit perfect through to the output stage) is fundamental, as is touching it if the user wishes so (replaygain, resampling, encoding to ac3 etc.)

From the osx-coreaudio branch: Better audio on OS X machines. I'll defer to phi2039 for the actual details, if he wishes to provide it.

Cheers,
Jonathan
Jmarshall is correct in his comments about masteraudio. The preliminary design document is available in the source tree. As I began work on it, I encountered some serious flaws in our lower-level interfaces and set out to fix those first, with an eye toward making the changes (mostly) reusable in masteraudio.

osx-coreaudio is primarily focused on improving passthrough support, minimizing or eliminating (if possible) any unnecessary handling of the audio streams, and providing a more flexible and robust interface to the CoreAudio subsystem. That being said, it cannot, on its own, remedy the 16-bit ceiling currently in place, as the interfaces defined elsewhere in the application impose this limit. I have also chosen not to change the hardware sample-rate to match the source sample-rate at this point, because additional probing will need to be performed to ensure that the change does not cause adverse affects to other applications. It will likely end up as an option in the hardware configuration when all is said and done. This branch is ready for testing. I expect that there will be some issues to iron out as different hardware is introduced into the mix, but overall I am satisfied with the architecture. After some initial testing of the branch, I will merge the changes into linuxport.
Many thanks for the info, and for your efforts, of course Smile I'll get into the testing soon, first I need to collect some more information on compiling etc. Then I hope I can make some useful comments.
See README.osx in the root dir of SVN for info Smile

http://xbmc.org/browser/branches/osx-cor...README.osx

Cheers,
Jonathan
Pages: 1 2