[vorbis-dev] integer pcm decode patch

[robert at moon.eorbit.net]

Hi!

I've spent the last few nights digging into the Vorbis source and working
to implement a vorbis_synthesis_pcmout_int() function that kicks out
interleaved int16_t pcm data.

I think its important to have this function available to make the
job for people using the codec a little easier. This function abstracts
out the conversion to int16_t and removes the extra overhead of
moving the pcm data over the processors data bus just to do the int16_t
conversion after the vorbis synthesize.

I've written that function and I've created a linux command line player
that reads a .ogg from stdin and writes the pcm samples to the OSS
sound drivers using the the vorbis_synthesis_pcmout_int() function.
The linux command line player (that's giving it too much credit, really)
is just like the encode/decode example limited to 44khz files.

The patch for these features can be found here:

   http://moon.eorbit.net/~robert/pcm16.patch

There is one slight problem with the vorbis_synthesis_pcmout_int()
function that I hope we can all solve as a team. I personally failed
to solve this problem, but I think it important to get this function into
the codebase before the first release. I trust once the format and the
interface settle there will be more focus on optimization and at that
time we should be able to solve the problem, if not before.

The problem occurs in block.c line 666 (!) and line 669 of the
patched sources. These two lines are the lines that I chose for
doing the double to int16_t conversion. The problem is that for
my test case this solution was actually a bit slower than the
normal vorbis_synthesis_pcmout() call, when the original goal of
this function was to make the decoder more efficient.

The problem is that with the synthesizer spitting out int16_t data it was
actually doing slightly more than twice the number of float multiplies than
the code that does the conversion as the very last step. This is due to the
nature of the synthesizer, since it may make multiple passes over the pcm
data as it overlaps/adds two windows together.

Finding a better place to do the int16_t conversion is the key solving this
problem.  Once solution that I looked into was having the mdct kick out
int16_t values, but without having access to and understanding the original
paper that the mdct code was based on I only made things worse.

I should really go an pay some attention to my girlfriend now...     

--ruaok         Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye -- robert at moon.eorbit.net  http://moon.eorbit.net/~robert

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/