[gst-devel] audio/raw float caps format

[David Schleef]

On Tue, Jun 24, 2003 at 09:22:22PM +1200, Steve Baker wrote:
> As far as int audio goes:
> What if someone writes an element which sits on top of pro-audio
> hardware that has 24 bit audio stored in 32 bits? Thats the sort of
> situation the width/depth property is for - I don't see it as a major
> burden to continue supporting it.
> 
> And as for float audio:
> I was under the impression that IEEE floats had no endianness issues.

The memory order of floats and doubles is different on PowerPC and
i386.  AFAIK, true big-endian and true little-endian are the only
memory orders in use, i.e., no weird DEC-endian analogue bullshit.

> As for the "slope" and "intercept" properties, wingo is right in that
> all our float audio stuff will have the same slope and intercept, but
> there might be (for example) scientific applications that require
> different slope and intercept.

Or, more likely, one might read data from a file where the
floats/doubles don't correspond to 1.0 == line level.  For gst-sci,
I've been using an entire different set of caps.

> Or there might be a hyper-optimised audio
> plugin which changes the slope to avoid having scaling its output
> buffers - leaving the scaling to some downstream element.

That's a really gross hack, but ok.

> I don't see the harm in being explicit about these things even though
> 99% of the time we're using the same hard-wired int and float caps.

It would be better if we could specify propertiess that have the
meaning: "This prop is optional, but if it exists, it must be XXX."

One limitation of the caps/props system is that you can't add a
property to a few elements, and expect them to play nicely with
all the rest.  In other words, it's not possible to require that
a peer pad understand a particular property.  So, if we defined
that float audio did _not_ have slope/intercept, and later, someone
added an element that uses slope/intercept, it would connect
incorrectly to elements that follow the policy.  Perhaps there is
a way around this, but I'm sure it's a hack.  I'd prefer to define
our caps policy to include as much as we can envision now, and
when (not if) that becomes limiting, at least it will be farther
down the road.



dave...