From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] plugin_ops.h fixes
Date: Mon, 08 Jul 2002 12:25:05 +0200
Sender: alsa-devel-admin@lists.sourceforge.net
Message-ID: <s5hadp2v7ni.wl@alsa2.suse.de>
References: <3D295521.A14C950@ladisch.de>
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Return-path: <alsa-devel-admin@lists.sourceforge.net>
In-Reply-To: <3D295521.A14C950@ladisch.de>
Errors-To: alsa-devel-admin@lists.sourceforge.net
List-Help: <mailto:alsa-devel-request@lists.sourceforge.net?subject=help>
List-Post: <mailto:alsa-devel@lists.sourceforge.net>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@lists.sourceforge.net?subject=subscribe>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=alsa-devel>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: alsa-devel@lists.sourceforge.net
List-Id: alsa-devel@alsa-project.org

At Mon, 08 Jul 2002 11:02:25 +0200,
Clemens Ladisch wrote:
> 
> This macro in plugin_ops.h
> 	#ifdef __i386__
> 	#define _get_triple_le(ptr) (*(u_int32_t*)(ptr) & 0xffffff)
> tries to access four bytes through the pointer. If the three bytes of
> valid data are at the end of a page and the next page isn't mapped,
> this results in an exception.

right...

> The companion macro
> 	#define _get_triple_be(ptr) (bswap_32(*(u_int32_t*)(ptr)) & 0xffffff)
> suffers from the same problem, and, additionally, is wrong (it lacks
> ">> 8" after the bswap).
> I fixed both macros by removing them. :-)
 
yes, thanks.


> There is a typo in get16_1230_B2.
> 
> The put16_labels array is declared as having 128 elements instead
> of 16.
> 
> The gets_* code doesn't correctly extend the sign of the value in every
> case.
> 
> put_12_A1 should have been put_12_29, and the codes for put_0123_* use
> the nonexistent macros as_s24/as_u24. (This doesn't really matter as
> put_* isn't used anyway.)
> 
> The _norms function appears to be badly broken (_min and _max
> interchanged, using 32/64 bits for 24/32 bit values). I didn't attempt
> to fix it as it isn't used, either.
 
yes.  we can remove this stuff.
Jaroslav, any plan to use still this one?

> And the summing/normalization code in pcm_route.c treats the sample as
> if it were unsigned.

nice spot.

patches are applied to cvs.


thanks,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf