Re: Re: About integer64

Re: Re: About integer64

[Abramo Bagnara]

Paul Davis wrote:
> 
> >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?

Not very much:
a) if 32 bit integer could be enough expressive, what's the problem to
truncate it in your driver?
b) if a 32 bit integer is not enough and a float is preferrable:
considered that an ieee754 floating point is in the form (1+man)*2^exp
what's the problem in converting it in your driver using ffs and some
shift?

With both way I don't see the two point you make:
1) why bother with signed vs unsigned
2) why use 64 bit integer

Of course if a 64 bit integer is the best way to represent/report the
value all is fine, but in this case I doubt that you don't have
available the 64th bit for the sign.

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

>Not very much:
>a) if 32 bit integer could be enough expressive, what's the problem to
>truncate it in your driver?

if i knew that this was true, i would do so. i don't know that. the
rms meters are the *only* registers on the h-dsp that are 64 bit, so i
assume there is some reason for this.

>b) if a 32 bit integer is not enough and a float is preferrable:
>considered that an ieee754 floating point is in the form (1+man)*2^exp
>what's the problem in converting it in your driver using ffs and some
>shift?

if the lkml crew see us using floating point in any form in the
kernel, we will attract complaints, even if we use integer operations
to do so. i am firmly convinced of this.

>With both way I don't see the two point you make:
>1) why bother with signed vs unsigned

for purity abramo! for purity!

>2) why use 64 bit integer
>
>Of course if a 64 bit integer is the best way to represent/report the
>value all is fine, but in this case I doubt that you don't have
>available the 64th bit for the sign.

that seems likely to me also. i suspect we have somewhere between 32
and 64 bits of information. 

i didn't say that i conclusively needed the sign bit - i was noting
that the current API doesn't make unsigned values possible.

_______________________________________________________________

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:
> 
> >b) if a 32 bit integer is not enough and a float is preferrable:
> >considered that an ieee754 floating point is in the form (1+man)*2^exp
> >what's the problem in converting it in your driver using ffs and some
> >shift?
> 
> if the lkml crew see us using floating point in any form in the
> kernel, we will attract complaints, even if we use integer operations
> to do so. i am firmly convinced of this.

I don't think so: try to fgrep for float in kernel source, you'll find
several place where they're stored (and I suppose for good reason).

Also I've read a recent post from Alan Cox explaining *how* to use
floating point in kernel space. This presuppose that it's not a serious
sin if it's justified.

> >2) why use 64 bit integer
> >
> >Of course if a 64 bit integer is the best way to represent/report the
> >value all is fine, but in this case I doubt that you don't have
> >available the 64th bit for the sign.
> 
> that seems likely to me also. i suspect we have somewhere between 32
> and 64 bits of information.
> 
> i didn't say that i conclusively needed the sign bit - i was noting
> that the current API doesn't make unsigned values possible.

Please specify that then, you know, Jaroslav is faster than the dust to
insert new features, if you make him to believe they're needed ;-)

Better to insert them when and *if* they're needed: maintanance is
easier in this 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

[James Courtier-Dutton]

Paul Davis wrote:

>>Not very much:
>>a) if 32 bit integer could be enough expressive, what's the problem to
>>truncate it in your driver?
>>    
>>
>
>if i knew that this was true, i would do so. i don't know that. the
>rms meters are the *only* registers on the h-dsp that are 64 bit, so i
>assume there is some reason for this.
>
>  
>
>>b) if a 32 bit integer is not enough and a float is preferrable:
>>considered that an ieee754 floating point is in the form (1+man)*2^exp
>>what's the problem in converting it in your driver using ffs and some
>>shift?
>>    
>>
>
>if the lkml crew see us using floating point in any form in the
>kernel, we will attract complaints, even if we use integer operations
>to do so. i am firmly convinced of this.
>
>  
>
>>With both way I don't see the two point you make:
>>1) why bother with signed vs unsigned
>>    
>>
>
>for purity abramo! for purity!
>
>  
>
>>2) why use 64 bit integer
>>
>>Of course if a 64 bit integer is the best way to represent/report the
>>value all is fine, but in this case I doubt that you don't have
>>available the 64th bit for the sign.
>>    
>>
>
>that seems likely to me also. i suspect we have somewhere between 32
>and 64 bits of information. 
>
>i didn't say that i conclusively needed the sign bit - i was noting
>that the current API doesn't make unsigned values possible.
>
>  
>
What is wrong with useing floats in the alsa-lib, and then casting them 
to uint64 for all calls to the kernel.
That way, the kernel only ever sees a uint64, but the application sees a 
nice float.

Cheers
James





_______________________________________________________________

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