Date: Wed, 15 Feb 2006 16:30:02 +0800 From: Ariff Abdullah <ariff@FreeBSD.org> To: kazuhito@ph.noda.tus.ac.jp Cc: freebsd-multimedia@FreeBSD.org Subject: Re: patch for 24-bit soft volume and uaudio's tiny fix Message-ID: <20060215163002.71c997ef.ariff@FreeBSD.org> In-Reply-To: <20051217194604.7e6c08dd.skywizard@MyBSD.org.my> References: <20051217.033715.343188712.kazuhito@ph.noda.tus.ac.jp> <20051217194604.7e6c08dd.skywizard@MyBSD.org.my>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Sat, 17 Dec 2005 19:46:04 +0800 Ariff Abdullah <skywizard@MyBSD.org.my> wrote: > On Sat, 17 Dec 2005 03:37:15 +0900 (JST) > Kazuhito HONDA <kazuhito@ph.noda.tus.ac.jp> wrote: > > Hello, > > > > We have already had a soft volume, feeder_volume_s16(). > > But it is of 16 bit. So 24-bit sound streams are > > always downgraded to 16-bit before soft volume > > even though a sound device has a 24-bit port. > > Thus 24-bit soft volume is necessary. > > > > This mail has a patch for 24-bit soft volume. > > I tried to use it with `SB Live! 24-bit external' > > and it worked. > > > > And the patch includes a fix of tiny mistakes in uaudio.c, too. > > > > uaudio.c: Obvious mistake that need to be fixed. > > feeder_volume.c: Ok, looks good. My concern is endianess issue, but > this can be ignored for now. I need to examine it > first. > > channel.c: Changes against feeder building process is a bit > sensitive, > some brute testing need to be done here. > (Especially to Kazuhito-san), Latest patchsets (rev. 091) contain: 1) 16/24/32bit feeder_volume 2) 16/24/32bit vchan mixing (default to 16, use sysctl or vchanformat kernel hint to toggle it). 3) Smarter (I would say *perfect*) format scoring during format chaining. 4) Endian/sign-free format conversion 5) Various fixups, especially on hardware, DMA buffer alignment 6) Samples processing are moving towards endian-safe, we just need to enclose varios PCM_READ/WRITE/CLAMP (sound.h) within BYTE_ORDER ifdefs. My concern is 24bit alignment. This patchset enforce strict alignment based on bytes-per-sample, so if the so called "24bit" hardware can really do 24bit alignment, it is pretty much OK. Otherwise, we probably need to swap AFMT_S24_XX -> AFMT_S32_XX within specific driver implementation. -- Ariff Abdullah FreeBSD [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD8uaOlr+deMUwTNoRAnm3AJ9MayVDw4bRGkUmYnAM/773bKa8BQCgggad b95V3p67vzvucswCq7RR/Yc= =3fGD -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060215163002.71c997ef.ariff>