[alsa-devel] Support for floating point controls?

[Takashi Iwai]

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