From owner-freebsd-multimedia Fri Mar 31 12: 1:52 2000 Delivered-To: freebsd-multimedia@freebsd.org Received: from gilgamesch.bik-gmbh.de (T1-Hansenet.BIK-GmbH.de [192.76.134.246]) by hub.freebsd.org (Postfix) with ESMTP id 87B1F37BAB4 for ; Fri, 31 Mar 2000 12:01:36 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id WAA95706; Fri, 31 Mar 2000 22:01:32 +0200 (MET DST) Date: Fri, 31 Mar 2000 22:01:32 +0200 From: Martin Cracauer To: gandalf@vilnya.demon.co.uk Cc: freebsd-multimedia@freebsd.org Subject: newpcm secondary dma buffer - why? Message-ID: <20000331220131.A95404@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cameron, multimedia folks, could you explain why the newpcm driver uses a secondary buffer to collect data before it transmits it to the soundcard? struct _pcm_channel { [...] snd_dbuf buffer2nd; }; Please don't say "it does buffering", I assume that :-) But so far I've been under the impression that such things are unneeded in today's soundcards and that it is extremly hard to get the mmap API to work with such a construction in between. Thanks Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message