From owner-freebsd-multimedia Fri Jul 18 08:06:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25165 for multimedia-outgoing; Fri, 18 Jul 1997 08:06:43 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25150 for ; Fri, 18 Jul 1997 08:06:40 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id IAA05006; Fri, 18 Jul 1997 08:03:37 -0700 (PDT) Message-Id: <199707181503.IAA05006@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: sound and dma ... In-reply-to: Your message of "Fri, 18 Jul 1997 11:07:33 +0200." <199707180907.LAA17413@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 08:03:37 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, The problem with eliminating functionality like is that it will render us uncompatible with the linux or with linux apps. SOUND_PCM_SUBDIVIDE is really use for setting the buffer size and to provide multiple buffers. The sound driver generates N number of buffers based upon the size of its pool and the the size of a buffer. The intent is eliminate clicks. There is also buffering done on sound cards such as the gus --- the gus as to pcm devices its native one and its cs4231 , on the native side the driver buffer up sound streams so the effect is double buffering. Regards, Amancio >From The Desk Of Luigi Rizzo : > looking at the dma code in the sound driver (dmabuf.c) it appears that > the driver supports the splitting of the buffers in a number of > sub-buffers, so that some can be initialized with data while another > one can be in use for the dma engine. This should serve to avoid clicks > and interruptions in the flow of sound data especially at high speeds. > > However: > - this mechanism really seems overkill, two buffers being sufficient > (and additional buffering can be implemented separately if needed); > > - i am not sure if the mechanism is really used at all. The default in > the code is to use only ONE buffer, and can be overridden only if > some application issues one of these two ioctls: > SOUND_PCM_SUBDIVIDE > SNDCTL_DSP_SUBDIVIDE > (and still... they could be implemented as nops and let two buffers > be the default as in pcaudio.) > > Can you please do a grep on the sources of your favourite sound > applications to see if they happen to use one of the two ioctls above ? > > In rewriting the dma code I would certainly prefer not to deal with this > overly complex mechanism and go with plain double buffering. > > Thanks > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________