* Support for floating point controls?
@ 2010-01-27 23:12 Eliot Blennerhassett
2010-02-01 16:43 ` Jaroslav Kysela
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Eliot Blennerhassett @ 2010-01-27 23:12 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for floating point controls?
2010-01-27 23:12 Support for floating point controls? Eliot Blennerhassett
@ 2010-02-01 16:43 ` Jaroslav Kysela
2010-02-01 16:57 ` Takashi Iwai
2010-02-01 18:13 ` James Courtier-Dutton
2010-02-02 10:08 ` Daniel Glöckner
2 siblings, 1 reply; 8+ messages in thread
From: Jaroslav Kysela @ 2010-02-01 16:43 UTC (permalink / raw)
To: Eliot Blennerhassett; +Cc: alsa-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for floating point controls?
2010-02-01 16:43 ` Jaroslav Kysela
@ 2010-02-01 16:57 ` Takashi Iwai
0 siblings, 0 replies; 8+ messages in thread
From: Takashi Iwai @ 2010-02-01 16:57 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Eliot Blennerhassett, alsa-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Support for floating point controls?
2010-01-27 23:12 Support for floating point controls? Eliot Blennerhassett
2010-02-01 16:43 ` Jaroslav Kysela
@ 2010-02-01 18:13 ` James Courtier-Dutton
2010-02-01 19:42 ` Eliot Blennerhassett
2010-02-02 10:08 ` Daniel Glöckner
2 siblings, 1 reply; 8+ messages in thread
From: James Courtier-Dutton @ 2010-02-01 18:13 UTC (permalink / raw)
To: Eliot Blennerhassett; +Cc: alsa-devel
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 (?)
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Support for floating point controls?
2010-01-27 23:12 Support for floating point controls? Eliot Blennerhassett
2010-02-01 16:43 ` Jaroslav Kysela
2010-02-01 18:13 ` James Courtier-Dutton
@ 2010-02-02 10:08 ` Daniel Glöckner
2010-02-02 10:44 ` Takashi Iwai
2 siblings, 1 reply; 8+ messages in thread
From: Daniel Glöckner @ 2010-02-02 10:08 UTC (permalink / raw)
To: Eliot Blennerhassett; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for floating point controls?
2010-02-02 10:08 ` Daniel Glöckner
@ 2010-02-02 10:44 ` Takashi Iwai
0 siblings, 0 replies; 8+ messages in thread
From: Takashi Iwai @ 2010-02-02 10:44 UTC (permalink / raw)
To: Daniel Glöckner; +Cc: Eliot Blennerhassett, alsa-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Support for floating point controls?
@ 2010-02-01 16:13 Tobias Schneider
0 siblings, 0 replies; 8+ messages in thread
From: Tobias Schneider @ 2010-02-01 16:13 UTC (permalink / raw)
To: alsa-devel, Eliot Blennerhassett
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-02-02 10:44 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-27 23:12 Support for floating point controls? Eliot Blennerhassett
2010-02-01 16:43 ` Jaroslav Kysela
2010-02-01 16:57 ` Takashi Iwai
2010-02-01 18:13 ` James Courtier-Dutton
2010-02-01 19:42 ` Eliot Blennerhassett
2010-02-02 10:08 ` Daniel Glöckner
2010-02-02 10:44 ` Takashi Iwai
-- strict thread matches above, loose matches on Subject: below --
2010-02-01 16:13 Tobias Schneider
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).