another control API issue

another control API issue

[Paul Davis]

the h-dsp has some 64 bit registers. the current control API doesn't
offer a way of representing such values. shall i add
      
      SNDRV_CTL_ELEM_TYPE_INTEGER64 

?

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Jaroslav Kysela]

On Tue, 7 May 2002, Paul Davis wrote:

> the h-dsp has some 64 bit registers. the current control API doesn't
> offer a way of representing such values. shall i add
>       
>       SNDRV_CTL_ELEM_TYPE_INTEGER64 
> 
> ?

Added, except for utilities.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Abramo Bagnara]

Paul Davis wrote:
> 
> the h-dsp has some 64 bit registers. the current control API doesn't
> offer a way of representing such values. shall i add
> 
>       SNDRV_CTL_ELEM_TYPE_INTEGER64
> 
> ?

Just for curiosity, what they store that cannot be represented in 32
bits?!?

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Paul Davis]

>Just for curiosity, what they store that cannot be represented in 32
>bits?!?

RMS meters. It seems that the 64 bit-ness comes from it being some
kind of fixed point representation - the value that you read from the
registers need scaling (in user space, presumably) by a floating point
transformation to actually become true RMS values. so its not so much
they they need 64 bits of precision, more that the hardware needs to
do the math with this type of data format. keep in mind the
computation is all being done on a Xilinx FPGA, not a DSP chip, so the
arithmetic options are (at this time) a bit limited.

--p


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Abramo Bagnara]

Paul Davis wrote:
> 
> >Just for curiosity, what they store that cannot be represented in 32
> >bits?!?
> 
> RMS meters. It seems that the 64 bit-ness comes from it being some
> kind of fixed point representation - the value that you read from the
> registers need scaling (in user space, presumably) by a floating point
> transformation to actually become true RMS values. so its not so much
> they they need 64 bits of precision, more that the hardware needs to
> do the math with this type of data format. keep in mind the
> computation is all being done on a Xilinx FPGA, not a DSP chip, so the
> arithmetic options are (at this time) a bit limited.

I expected something similar. Don't you think that to have a FLOAT type
is a better choice (more card independent, more accessible, more
representative, etc.).

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Paul Davis]

>I expected something similar. Don't you think that to have a FLOAT type
>is a better choice (more card independent, more accessible, more
>representative, etc.).

Well, that was my initial thought. Then I remembered that we can't
have floating point code in the kernel, and its therefore unsafe to
even use this data type (an interrupt in kernel mode doesn't result in
an FP register restore, and we may have run another task in the
meantime that used the FP registers before we get back to our code).

In this particular case, even if it was safe to store the value in a
float, the actual float value has to be computed with FP math, which
is definitely not available in the kernel. so it wouldn't help much
here.

Sound right?

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Abramo Bagnara]

Paul Davis wrote:
> 
> >I expected something similar. Don't you think that to have a FLOAT type
> >is a better choice (more card independent, more accessible, more
> >representative, etc.).
> 
> Well, that was my initial thought. Then I remembered that we can't
> have floating point code in the kernel, and its therefore unsafe to
> even use this data type (an interrupt in kernel mode doesn't result in
> an FP register restore, and we may have run another task in the
> meantime that used the FP registers before we get back to our code).
> 
> In this particular case, even if it was safe to store the value in a
> float, the actual float value has to be computed with FP math, which
> is definitely not available in the kernel. so it wouldn't help much
> here.
> 
> Sound right?

Not fully. You can use FPU in kernel space with some attention (disable
preemption and save/restore FPU state for critical area).

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Paul Davis]

>> Sound right?
>
>Not fully. You can use FPU in kernel space with some attention (disable
>preemption and save/restore FPU state for critical area).

Sure, you can do this, but if anyone from lkml gets a look at it, it
won't last very long :)

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: another control API issue

[Abramo Bagnara]

Paul Davis wrote:
>>>Sound right?
>>
>>Not fully. You can use FPU in kernel space with some attention (disable
>>preemption and save/restore FPU state for critical area).
> 
> 
> Sure, you can do this, but if anyone from lkml gets a look at it, it
> won't last very long :)
> 

An alternative is to cope with ieee754 without FPU. I cannot know about 
your specific case, but I guess it would be easy.


-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net