[vorbis-dev] integer pcm decode patch

[Michael Smith]

At 01:41 PM 4/19/00 -0700, you wrote:
>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.

vorbisfile does this. It's also an order of magnitude easier to use - a
minimal example requires precisely three functions. It leaves the
conversion to 16 bit ints to later (after vorbis_synthesis_pcmout()) - but
realistically, that data will be sitting around in L2 cache most likely, so
there isn't significant extra overhead. Right now, it's pretty slow. A
minor modification to a single line makes it roughly 10% faster (for fully
decoding a single bitstream, ~4 minutes long), so I'll clean up that (it's
all in ov_read()) and commit it. Well, after making sure it DOES give the
same results (which it should).

>
>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.

Thanks, this player might be useful for when I can't be bothered firing up
xmms. I'll try it out later.

>
>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.

Well, I think this is probably the wrong place to do it - though it might
be advantagous to have something akin to the sample conversion routines in
vorbisfile moved into libvorbis itself - it's definately best done AFTER
the rest of the decoding, in my opinion.

>
>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/