All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abramo Bagnara <abramo@alsa-project.org>
To: Paul Davis <pbd@op.net>
Cc: Jaroslav Kysela <perex@perex.cz>, alsa-devel@lists.sourceforge.net
Subject: Re: Re: About integer64
Date: Thu, 09 May 2002 15:25:34 +0200	[thread overview]
Message-ID: <3CDA78CE.BE2D0F56@alsa-project.org> (raw)
In-Reply-To: 200205091256.OAA26239@alsa.alsa-project.org

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

       reply	other threads:[~2002-05-09 13:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200205091256.OAA26239@alsa.alsa-project.org>
2002-05-09 13:25 ` Abramo Bagnara [this message]
2002-05-09 13:40   ` Re: About integer64 Paul Davis
2002-05-09 13:56     ` Abramo Bagnara
2002-05-11 15:19     ` James Courtier-Dutton
2002-05-09 11:07 Paul Davis
2002-05-09 12:32 ` Abramo Bagnara
2002-05-09 12:57   ` Paul Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CDA78CE.BE2D0F56@alsa-project.org \
    --to=abramo@alsa-project.org \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=pbd@op.net \
    --cc=perex@perex.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.