Date: Fri, 18 Jul 1997 08:03:37 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG Subject: Re: sound and dma ... Message-ID: <199707181503.IAA05006@rah.star-gate.com> In-Reply-To: Your message of "Fri, 18 Jul 1997 11:07:33 %2B0200." <199707180907.LAA17413@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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/ > _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707181503.IAA05006>