At Tue, 02 Feb 2010 11:08:10 +0100,
Daniel Glöckner wrote:
>
> On 01/28/2010 12:12 AM, Eliot Blennerhassett wrote:
> > I wonder if a patch implementing float ctl elements would be accepted?
> > Note that the floats are not manipulated in the kernel at all, the
> > values are just passed through from the hardware to userspace (?)
> >
> > Adding something like:
> >
> > #define SNDRV_CTL_ELEM_TYPE_FLOAT ((__force snd_ctl_elem_type_t) 7)
> >
> > struct snd_ctl_elem_info {
> > ...
> > union {
> > struct {
> > float min; /* R: minimum value */
> > float max; /* R: maximum value */
> > float step; /* R: step (0 variable) */
> > } float;
> > ...
> > }
> >
> > struct snd_ctl_elem_value {
> > union {
> > union {
> > float value[128];
> > } float;
>
> I see several issues here.
> There might be some day an architecture where float is not the
> IEEE 754 single precision type. Or there might be a compiler that
> insists on using floating point instructions to read those values
> from memory. Therefore I prefer __s32 here instead of float.
>
> Drivers would have to check if a passed control value is in the
> range [min, max] and filter out INFs and NANs. So one needs to
> implement an in-kernel version of C99's fpclassify and isgreater
> working on floating point values kept in integer variables for
> all drivers to use.
>
> Alsa-lib may need to convert the IEEE floats to the native floats
> if they are not the same. Just look at the issues with double on
> ARM. There the order of the two 32 bit halves in memory depends on
> the ABI IIRC.
Well, I think you see way too far unnecessarily :)
In the kernel level, we won't handle any FP operations.
If any, the driver could, but it should be a specific way.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
