About integer64

About integer64

[Abramo Bagnara]

I don't think that's a bad thing to have support for 64 bit integers
(perhaps for future use, who knows), but I think that to use this to
store a fixed point float is a big mistake.

If you think for it you realize that it's *not* an integer and
applications are betrayed in their expectation.

I see two possible solutions:
1) convert internal representation to float (or double) and add support
for this type of data
2) use SNDRV_CTL_ELEM_TYPE_BYTES

As I've already said I prefer 1) but too 2) is far better that to have a
wrong use of a data type.

-- 
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: About integer64

[Jaroslav Kysela]

On Thu, 9 May 2002, Abramo Bagnara wrote:

> 
> I don't think that's a bad thing to have support for 64 bit integers
> (perhaps for future use, who knows), but I think that to use this to
> store a fixed point float is a big mistake.
> 
> If you think for it you realize that it's *not* an integer and
> applications are betrayed in their expectation.
> 
> I see two possible solutions:
> 1) convert internal representation to float (or double) and add support
> for this type of data
> 2) use SNDRV_CTL_ELEM_TYPE_BYTES
> 
> As I've already said I prefer 1) but too 2) is far better that to have a
> wrong use of a data type.

I fully agree. We can add a float type when necessary, but only when it
follows IEEE-754. Hardware specific formats should be encapsulated into
more generic types...

						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: About integer64

[Paul Davis]

>
>I don't think that's a bad thing to have support for 64 bit integers
>(perhaps for future use, who knows), but I think that to use this to
>store a fixed point float is a big mistake.
>
>If you think for it you realize that it's *not* an integer and
>applications are betrayed in their expectation.

in this case, it *is* an integer. your original question was about why
its 64 bits - i think that comes from the fixed point internal
arithmetic. but the end result is a straightforward 64 bit little
endian integer that needs scaling to get the actual RMS value.

which actually creates another problem that i've noticed with the
control API. INTEGER and INTEGER64 assume that the control value is
signed. there is no way to infer from the control element info that
its unsigned. this isn't a "deep" problem, but it will mess up user
interfaces that present a large unsigned value and end up displaying
it as a negative number.

--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: Re: About integer64

[Abramo Bagnara]

Paul Davis wrote:
> 
> >
> >I don't think that's a bad thing to have support for 64 bit integers
> >(perhaps for future use, who knows), but I think that to use this to
> >store a fixed point float is a big mistake.
> >
> >If you think for it you realize that it's *not* an integer and
> >applications are betrayed in their expectation.
> 
> in this case, it *is* an integer. your original question was about why
> its 64 bits - i think that comes from the fixed point internal
> arithmetic. but the end result is a straightforward 64 bit little
> endian integer that needs scaling to get the actual RMS value.

You wrote:

> 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.

What I'm misunderstanding? I tend to interpret the former and the latter
statements in a contradictory way.

-- 
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: Re: About integer64

[Paul Davis]

>What I'm misunderstanding? I tend to interpret the former and the latter
>statements in a contradictory way.

my reading of the "docs" (the Mac OS X driver and utilities) is that
RME haven't figured out a way to truncate the 64 bit fixed point
representation to a 32 bit integer using the Xilinx FPGA. they have
figured out how to render it as a 64 bit integer. so, they do the math
using a fixed point representation, then transform to 64 bit integer
when storing it in the register. the final part of the transform is
done by the host CPU, in our case up in user space since we can't do
float math conveniently in the kernel.

does that make it clearer?

--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: About integer64

[Jaroslav Kysela]

On Thu, 9 May 2002, Paul Davis wrote:

> >I don't think that's a bad thing to have support for 64 bit integers
> >(perhaps for future use, who knows), but I think that to use this to
> >store a fixed point float is a big mistake.
> >
> >If you think for it you realize that it's *not* an integer and
> >applications are betrayed in their expectation.
> 
> in this case, it *is* an integer. your original question was about why
> its 64 bits - i think that comes from the fixed point internal
> arithmetic. but the end result is a straightforward 64 bit little
> endian integer that needs scaling to get the actual RMS value.
> 
> which actually creates another problem that i've noticed with the
> control API. INTEGER and INTEGER64 assume that the control value is
> signed. there is no way to infer from the control element info that
> its unsigned. this isn't a "deep" problem, but it will mess up user
> interfaces that present a large unsigned value and end up displaying
> it as a negative number.

I think that we can add 'int unsign: 1;' to sndrv_ctl_elem_info for 
integer and integer64. Any objections?

						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: About integer64

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Thu, 9 May 2002, Paul Davis wrote:
> 
> > >I don't think that's a bad thing to have support for 64 bit integers
> > >(perhaps for future use, who knows), but I think that to use this to
> > >store a fixed point float is a big mistake.
> > >
> > >If you think for it you realize that it's *not* an integer and
> > >applications are betrayed in their expectation.
> >
> > in this case, it *is* an integer. your original question was about why
> > its 64 bits - i think that comes from the fixed point internal
> > arithmetic. but the end result is a straightforward 64 bit little
> > endian integer that needs scaling to get the actual RMS value.
> >
> > which actually creates another problem that i've noticed with the
> > control API. INTEGER and INTEGER64 assume that the control value is
> > signed. there is no way to infer from the control element info that
> > its unsigned. this isn't a "deep" problem, but it will mess up user
> > interfaces that present a large unsigned value and end up displaying
> > it as a negative number.
> 
> I think that we can add 'int unsign: 1;' to sndrv_ctl_elem_info for
> integer and integer64. Any objections?

I'd avoid that.

About the problem Paul has shown the important thing is to know if all
64 bits are used. This is also the reason why I've asked the original
question: I can't imagine a quantity in audio problem space that need 64
bit of resolution and all the bits are significant and they make a
sensible difference.

However also if this is the case I'd prefer to have UINTEGER and/or
UINTEGER64.


-- 
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: About integer64

[Paul Davis]

>However also if this is the case I'd prefer to have UINTEGER and/or
>UINTEGER64.

I agree. I would prefer specific types for unsigned controls, not an
extra bit to indicate this. imagine:

      switch (control->type) {
      case INTEGER:
           if (control->unsigned) {
	      ...
	   } else {
	      ...
	   }
	   break;

versus:
      
       switch (control->type) {
       case INTEGER:
           ...
	   break;
       case UINTEGER:
           ...
	   break;

i much prefer the latter.
	   
--p

_______________________________________________________________

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