At Mon, 1 Feb 2010 17:43:22 +0100 (CET), Jaroslav Kysela wrote:

On Thu, 28 Jan 2010, Eliot Blennerhassett wrote:

...

Greetings,

some of our products now have control paramters that are 32 bit floating point values.

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 (?)

If hardware supports this format, I have no objections against this extension.

...

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 think this isn't allowed in C. The field name should be _float or so...

Looks good. Also, don't forget to add the support for this type to alsa-lib.

And don't forget to add a protocol-version check there, too.

thanks,

Takashi

James Courtier-Dutton wrote:

Which hardware supports these 32 bit float controls?

For our (http://audioscience.com/internet/products/sound_cards/soundcards.htm) cards, none officially yet.

However, we are working on extensions to our control protocol that allows float parameters, which naturally express the parameters of some of the controlled algorithms on the card/boxes. (The processor on the cards is a floating point DSP)

It would then be a pain if ALSA did not support float controls, because we'd have to convert from float to int in the kernel to pass to userspace, where probably it would need to be rescaled to int again...

-- Eliot

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