From owner-freebsd-multimedia Wed Jul 21 16: 1:38 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 593F9155AA for ; Wed, 21 Jul 1999 16:01:22 -0700 (PDT) (envelope-from gandalf@vilnya.demon.co.uk) Received: from vilnya.demon.co.uk ([158.152.19.238]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 1175MG-000HLb-0B for multimedia@freebsd.org; Wed, 21 Jul 1999 23:01:04 +0000 Received: from nenya (nenya.rings [10.2.4.3]) by vilnya.demon.co.uk (8.9.3/8.9.1) with SMTP id AAA76863 for ; Thu, 22 Jul 1999 00:07:42 +0100 (BST) (envelope-from gandalf@vilnya.demon.co.uk) Message-ID: <002301bed3cd$434f9d00$0304020a@rings> From: "Cameron Grant" To: Subject: Fw: newpcm writeup Date: Thu, 22 Jul 1999 00:03:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org oops, this was intended for the list, not just luigi. > > > If i assume that this is indeed the case, then why would you do it in > > > sw? Dont most of the MSS or SB based cards have registers that you set > > > to inform the card that it's getting/(or expected to output) a given > > > format? > > some such cards do not support all formats one would desire, or they do > > in the data sheets but the chip is broken. > > the conversion is present also in voxware and pcm just for the reason > > above. > > as luigi said, the purpose is to provide a consistent set of formats > supported across all cards. a lot of cards don't support ulaw at all, so > require software conversion to support /dev/audio. older cards don't do 16 > bit or stereo. also, with the ability to add arbitary filters to the audio > pipeline, we gain the possibility of more interesting things like 3d > positional audio- this could be done in hw if specifications were available. > > > a nicer feature would be to do conversion of *sampling rate*, and here > > i agree with you that the card should do this if possible, not the CPU. > > sample rate conversion would require minor modifications to allow disparate > hardware and logical rates in the same way as formats work. i'll probably > implement it eventually. > > > > My limited experience with sound and video processing would lead me to > > > conclude that one would rather have the *card* burn cycles on formats > > > instead of the *cpu*, because the card will just have to wait on the > > > cpu otherwise. > > when the card can do it, it does. when it can't, the cpu power required to > do it for it is miniscule- several years ago i was mixing 8 channels of 16 > bit audio upconverted from 8 bit, and resampled with linear interpolation > using about 15% cpu on a 386/40. translate that to a modern cpu and forget > about the mixing and you'll not be able to tell what is done in sw. > > - cameron > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message