From: Abramo Bagnara <abramo.bagnara@libero.it>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Clemens Ladisch <clemens@ladisch.de>,
"alsa-devel@lists.sourceforge.net"
<alsa-devel@lists.sourceforge.net>
Subject: Re: [PATCH] plugin_ops.h fixes
Date: Thu, 11 Jul 2002 00:20:21 +0200 [thread overview]
Message-ID: <3D2CB325.FB7CA340@libero.it> (raw)
In-Reply-To: Pine.LNX.4.33.0207101418080.504-100000@pnote
Jaroslav Kysela wrote:
>
> On Tue, 9 Jul 2002, Abramo Bagnara wrote:
>
> > > > > > And the summing/normalization code in pcm_route.c treats the sample as
> > > > > > if it were unsigned.
> > > >
> > > > Be careful here. Use of signed vs. unsigned was an hard decision.
> > > > Can you point me exactly where you see a problem?
> > >
> > > In the following code snippet
> > >
> > > add_int64_att:
> > > sum.as_sint64 += (u_int64_t) sample * ttp->as_int;
> > >
> > > each of the three variables has a signed integer type. Converting
> > > the sample from int32_t to u_int64_t would give wrong results for
> > > negative values, e.g., the sample -1 (0xffffffff) would be converted
> > > to 4294967295 (0x00000000ffffffff).
> > >
> > > The following code
> > >
> > > norm_int:
> > > if (sum.as_sint64 > (u_int32_t)0xffffffff)
> > > sample = (u_int32_t)0xffffffff;
> > > else
> > > sample = sum.as_sint64;
> > >
> > > doesn't check for negative values of sum.as_sint64. Additionally,
> > > using 0xffffffff in case of overflow results in sample == -1.
> > >
> > > These code snippets would be correct if the sample would be unsigned,
> > > but my point was that this isn't the case.
> >
> > I've just checked: this has been broken by Jaroslav with CVS version
> > 1.55. I'd like to restore the original behaviour I wrote (that used
> > unsigned for efficiency reason), but I don't understand what Jaroslav
> > tried to solve.
> >
> > Jaroslav?
>
> You cannot use unsigned values, because we need to sum samples (it means:
> add positive and substract negative ones). If we are in positive range, we
> can only add samples, so the final sum result is wrong.
Wow, I've never realized this...
So mixing can only be done with signed values, otherwise we have bogus
value for overranges. Right?
Taken this in account, I'm tempted to consider unsigned formats as
second class citizen (i.e. format hard to handle and with some added
difficulties wrt manipulation). I'm wrong?
--
Abramo Bagnara mailto:abramo.bagnara@libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
next prev parent reply other threads:[~2002-07-10 22:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-08 9:02 [PATCH] plugin_ops.h fixes Clemens Ladisch
2002-07-08 10:25 ` Takashi Iwai
2002-07-08 17:07 ` Abramo Bagnara
2002-07-09 8:36 ` Clemens Ladisch
2002-07-09 9:23 ` Abramo Bagnara
2002-07-09 11:23 ` Clemens Ladisch
2002-07-09 12:12 ` Takashi Iwai
2002-07-09 12:21 ` Clemens Ladisch
2002-07-09 12:45 ` Takashi Iwai
2002-07-09 20:20 ` Abramo Bagnara
2002-07-10 12:21 ` Jaroslav Kysela
2002-07-10 13:21 ` another problems with signed arithmetic snd_pcm_mmap_playback_avail tomasz motylewski
2002-07-10 16:32 ` tomasz motylewski
2002-07-10 22:20 ` Abramo Bagnara [this message]
2002-07-11 8:00 ` [PATCH] plugin_ops.h fixes Jaroslav Kysela
2002-07-11 8:37 ` Clemens Ladisch
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=3D2CB325.FB7CA340@libero.it \
--to=abramo.bagnara@libero.it \
--cc=alsa-devel@lists.sourceforge.net \
--cc=clemens@ladisch.de \
--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.