All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abramo Bagnara <abramo@alsa-project.org>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Paul Davis <pbd@op.net>,
	"alsa-devel@lists.sourceforge.net"
	<alsa-devel@lists.sourceforge.net>
Subject: Re: About integer64
Date: Thu, 09 May 2002 14:27:52 +0200	[thread overview]
Message-ID: <3CDA6B48.3E68AE3A@alsa-project.org> (raw)
In-Reply-To: Pine.LNX.4.33.0205091316530.482-100000@pnote.perex-int.cz

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

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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200205091107.NAA14247@gate.perex.cz>
2002-05-09 11:18 ` About integer64 Jaroslav Kysela
2002-05-09 12:27   ` Abramo Bagnara [this message]
2002-05-09 12:59     ` Paul Davis
2002-05-09  8:10 Abramo Bagnara
2002-05-09 10:37 ` Jaroslav Kysela
2002-05-09 11:07 ` 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=3CDA6B48.3E68AE3A@alsa-project.org \
    --to=abramo@alsa-project.org \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=pbd@op.net \
    --cc=perex@suse.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.