RE: [gst-devel] audio/raw = 16 bit int?

[Steve B. <sb...@ch...>]

I agree that sometimes you really needs the accuracy of floating point, but
at other times you really need the speed of 16bit ints.  Ultimately it would
be good to see all audio filter elements have implementations for both int
and float.  

In the future it may be possible for gstreamer to automatically insert
conversion elements into the chain if a particular element is missing an
implementation for a particular raw audio format.  It would be slower, but
thats the punishment!

> -----Original Message-----
> From: Wim Taymans [mailto:wim...@ch...]
> Sent: 09 March 2001 18:13
> To: gst...@li...
> Subject: Re: [gst-devel] audio/raw = 16 bit int?
> 
> 
> On 09 Mar 2001 17:35:00 +0100, Owen Fraser-Green wrote:
> > Hi,
> > 
> > A quick question regarding audio/raw. I noticed sample resolution 
> > (MetaAudioRaw->bps) must be AFMT_S(8|16)_LE and audio data 
> is passed as 
> > integers. Woudn't it be better for audio/raw to be 32-bit 
> floats? By using 
> > 16-bit signal processing, even (especially) if the output 
> resolution is 16-
> > bit, aliasing effects can easily be introduced. It also 
> means that there 
> > are currently a lot of "magic" numbers floating around 
> (because the range 
> > is 0 to 2^16-1 instead of just -1 to 1) plus there's a lot 
> of casting going 
> > on e.g. sinesrc and volume. 
> 
> yes, but only when we have caps negotiation working. The 
> properties you
> attach to
> a pad can then be anything you want. You also will have to create a
> converter that does
> the float to int conversion so that common cards can handle the data.
> 
> Wim
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gst...@li...
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>