Support for floating point controls?

Support for floating point controls?

[Tobias Schneider]

I was searching for floating point controls and found your post. I would 
also appreciate such a define, but I also found an answer that might 
still be "up to date" 
http://thread.gmane.org/gmane.linux.alsa.devel/1498/focus=1507

Support for floating point controls?

[Eliot Blennerhassett]

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

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;


--
Eliot Blennerhassett
AudioScience Inc

Re: Support for floating point controls?

[Jaroslav Kysela]

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;

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


 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Support for floating point controls?

[Takashi Iwai]

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

Re: Support for floating point controls?

[James Courtier-Dutton]

Which hardware supports these 32 bit float controls?


On 27 January 2010 23:12, Eliot Blennerhassett <linux@audioscience.com> 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 (?)
>

Re: Support for floating point controls?

[Eliot Blennerhassett]

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

Re: Support for floating point controls?

[Daniel Glöckner]

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.

Just my 2 cents

  Daniel


-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner

Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel