All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abramo Bagnara <abramo.bagnara@libero.it>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Jaroslav Kysela <perex@perex.cz>, alsa-devel@lists.sourceforge.net
Subject: Re: [PATCH] plugin_ops.h fixes
Date: Tue, 09 Jul 2002 11:23:42 +0200	[thread overview]
Message-ID: <3D2AAB9E.C401BD17@libero.it> (raw)
In-Reply-To: 3D2AA09B.12C7B125@ladisch.de

Clemens Ladisch wrote:
> 
> Abramo Bagnara wrote:
> > min & max are interchanged indeed. My bad...
> 
> Oh, there's no problem with using _max instead of _min  -- I just
> noticed that the code for _max writes 0 for unsigned 16/24/32-bit
> values ...  ;o)

Fixed now in CVS.

> 
> > Use of 32/64 bits for 24/32 bit is wanted. Take in account that this
> > function is called on mix results (where I need to avoid wrap before
> > normalization).
> 
> Then it should use bigger types for 8/16 bits, too. Checking for a type
> to overflow its own valid range seems to be rather pointless to me.

It *does* use bigger types.

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

-- 
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
Stuff, things, and much much more.
http://thinkgeek.com/sf

  reply	other threads:[~2002-07-09  9:23 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 [this message]
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           ` [PATCH] plugin_ops.h fixes Abramo Bagnara
2002-07-11  8:00             ` 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=3D2AAB9E.C401BD17@libero.it \
    --to=abramo.bagnara@libero.it \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=clemens@ladisch.de \
    --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.