[vorbis-dev] mdct.c

[Pattara Kiatisevi]

Hmm, I have some quite stupid questions. The data in Ogg/Vorbis file -->
each sample = int 16-bit word? And output pcm data also = int 16-bit word?
If yes then..

-why is the conversion to float back and forth needed? Is there any
particular benefit as the reason to choose floating point at the time you
implemented the MDCT code?
-is there any limit (or reasonable limit) of this floating point input &
output data value for MDCT? From my observation I see that the range is
between -1 to 1.

Thank you very very much,
Pattara


--
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
----------------------------------------------------------------------
Ott Pattara Kiatisevi 				   T L W G
M.Sc. INFOTECH Student, Stuttgart, Germany	http://linux.thai.net/
----------------------------------------------------------------------

On Wed, 20 Mar 2002, Pattara Kiatisevi wrote:

> Hi,
>
> Firstly thank you for the answer.
>
> On Mon, 18 Mar 2002, Monty wrote:
>
> >
> > > As we're trying to put libvorbis on LEON chip running on XSV-800 FPGA
> > > board, the code runs now (simple player using Pthread on RTEMS/LEON)  but
> > > it seems that we have to implement some functions in hardware in order to
> > > help speed up the decoding process. We target this mdct_backward()
> > > first. Do you have any comment? Is there any other hardware-friendly and
> > > computation-intensive functions?
> >
> > Most other operations are vectorizable...  The LSP filter code (only
> > used by re-pc bitstreams) could also benefit from
> 	  ^^^^^	Hmm, what is this re-pc?
>
> There doesn't seem to be the calls vorbis_lsp_to_curve in my player
> code so far. Not sure in which situation it will be used.
>
> Ok, from your information then I go for CVS code. I noticed an
> option"#define MDCT_INTEGERIZED" in mdct.h so I tried it. Hmm, the sound
> output is likely not correct and I checked the result of mdct_backward
> compared to the floating point version, they are not really similar(see
> below). So this is the work to be done, right? Or I am missing something.
>
> [floating point]
> Calling mdct_init functions...
> Calling mdct_backward functions...
> Output values:
> Value at 0x0804BC80 : 44.019447
> Value at 0x0804BC84 : -43.652561
> Value at 0x0804BC88 : 42.087036
> Value at 0x0804BC8C : -41.769104
> Value at 0x0804BC90 : 40.410435
> Value at 0x0804BC94 : -40.134113
> Value at 0x0804BC98 : 38.952457
> Value at 0x0804BC9C : -38.712002
> Value at 0x0804BCA0 : 37.683647
> Value at 0x0804BCA4 : -37.474438
> Value at 0x0804BCA8 : 36.580189
> Value at 0x0804BCAC : -36.398438
> Value at 0x0804BCB0 : 35.622883
> Value at 0x0804BCB4 : -35.465591
> Value at 0x0804BCB8 : 34.796074
> Value at 0x0804BCBC : -34.660736
> Value at 0x0804BCC0 : 34.087040
> Value at 0x0804BCC4 : -33.971611
> Value at 0x0804BCC8 : 33.485340
>
> [intergerized]
> Calling mdct_init functions...
> Calling mdct_backward functions...
> Output values:
> Value at 0x0804B360 : 31.000000
> Value at 0x0804B364 : -51.000000
> Value at 0x0804B368 : 37.000000
> Value at 0x0804B36C : -51.000000
> Value at 0x0804B370 : 41.000000
> Value at 0x0804B374 : -41.000000
> Value at 0x0804B378 : 37.000000
> Value at 0x0804B37C : -41.000000
> Value at 0x0804B380 : 36.000000
> Value at 0x0804B384 : -36.000000
> Value at 0x0804B388 : 35.000000
> Value at 0x0804B38C : -33.000000
> Value at 0x0804B390 : 34.000000
> Value at 0x0804B394 : -37.000000
> Value at 0x0804B398 : 34.000000
> Value at 0x0804B39C : -33.000000
> Value at 0x0804B3A0 : 36.000000
> Value at 0x0804B3A4 : -30.000000
> Value at 0x0804B3A8 : 36.000000
> Value at 0x0804B3AC : -31.000000
>
> [cut]
>
> I saw you mentioned about multiplication of int and the magic workaround
> (as C union or so). Is the code somewhere in CVS? I'm compiling on x86
> platform.
>
> Thank you very much,
> Pattara
>
>
> > Secondly, the fixed-point conversion done in the code can't handle the
> > range necessary to deal with Vorbis 1.0 files; the range behavior
> > hardwired into the implementation was mostly sufficient for beta four,
> > but the codebooks and multiplication vectors for 1.0 simply can't fit
> > in 32 bits with a fixed point.  32.32 would work, as would a binary
> > point that could move within a 32 bit range (ARM cores can give this
> > to an only mildly clever implementation for free; this is the approach
> > I've taken).
> >
> > So, in summary, the ivdev code is a fork of Vorbis from a long time
> > ago and doesn't reflect the stacks of bugfixes or complete 1.0 feature
> > set.  It does not work with any Ogg files produced by an Ogg encoder
> > from the past year or so, and it's my humble [but correct] opinion
> > that starting over with a fixed point port from current CVS is an
> > easier task than bringing ivdev up to date.
> >
> > Monty
> >
> > --- >8 ----
> > List archives:  http://www.xiph.org/archives/
> > Ogg project homepage: http://www.xiph.org/ogg/
> > To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
> > containing only the word 'unsubscribe' in the body.  No subject is needed.
> > Unsubscribe messages sent to the list will be ignored/filtered.
> >
> >
>
>
>
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
>
>

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.