Alsa-Devel Archive on 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 14:32:50 +0200	[thread overview]
Message-ID: <3CDA6C72.42150590@alsa-project.org> (raw)
In-Reply-To: E175llC-0006zb-00@usw-sf-list1.sourceforge.net

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

  reply	other threads:[~2002-05-09 12:32 UTC|newest]

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

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=3CDA6C72.42150590@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox