My changes to xine in the audio conversion branch are improving step by step; now all the decoders should playback fine, with their maximum resolution, by using the 32-bit floating point format as highest upscale. AC3 files are still a problem, although thanks to moesaji I now know that the mysterious function reduces the value basically by a value of 383 units; it’s still a mystery to me as I have no idea why that happens, and I can’t seem to find any documentation about these magic numbes for other stuff but a52dec.
Anyway, beside a52dec, most of other decoders are already fixed for the new interface, and I’ve started working on updating the ALSA audio output plugin; unfortunately the code of that plugin is ugly and complex, and seems to be a great big compendium of bad code style. With my changes in the audio conversion branch, the size of the initialisation function was reduced by 1KB, which is far from being small. It should also reduce the number of strings to translate, as I’ve used two loops rather than unrolling the tests for the capabilities of ALSA devices, which then condensed the number of strings to translate (they are composed during output, rather than being complete literals).
Hopefully the audio conversion branch will be merged into 1.2 series as soon as all the audio output plugins are converted, and a few more audio conversions routines are written. As the conversions are all limited to a single source file, it should also be quite easy to write more optimised routines using SIMD extensions for various architectures.
By working on this I ended up applying a few changes to 1.2 series itself already, by removing a few members from the decoder’s state structure for many plugins, and putting them into the functions they are used (why declare them in a state structure that is allocated in heap and passed, by pointer, everywhere, when they are used only in a single function? Sometimes even in a single branch of a given function.
The nice parts are that for instance NSF files now playback with a smaller memory footprint, as the buffer is allocated only when needed, and in the audio conversion branch also reduces the whole xine-lib memory footprint by two megabytes, this result means that to playback an mp3 file, xine-lib-1.2-audio-conversion takes half the memory xine-lib-1.1 takes! It’s incredible, but it’s true.
There are a lot more improvements that I hope to push into xine-lib-1.2, one of these is the splitting out of the modplug demuxer on its own plugin, so that binary distributions can just package it separately, allowing users wanting mod playback to actually get it, and saving the ones who cares not about mod files from having to initialise libmodplug every time (it takes quite a bit of CPU time, because of the calculation of the samples, I think I’ll post some images about this in the next days).
Oh and I’m actually thinking of reducing even more the code present in the decoders, by handling also the downmixing into the audio output loop (currently at least A52, DTS and Vorbis decoders contains the code to handle that) and by providing the code to handle also channels’ interleaving, as currently the same plugins also contain the same code, once again.
This again is to allow providing optimisations if possible, although I admit I’m not sure which kind of optimisation can be handled here. Still, it should be better to only have a copy of the code, rather than an undefined number…
So, you mean, it will be possible to decode music files (mp3, flac, etc) to 32-bit and send them in that format to DSP or ALSA? It would be really cool, so any DSP processing, in e.g. music players could be applied in full resolution and then downsampled with ALSA or other thing to desired format on output to soundcard.
Yes you got it right. FLAC files usually decode to 16 or 24 bits only, but mp3s are decoded by libmad as 32-bit, as well as musepack files decoded with libmpcdec, and so on.