From owner-freebsd-multimedia Mon Jul 21 00:47:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28292 for multimedia-outgoing; Mon, 21 Jul 1997 00:47:31 -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 AAA28287 for ; Mon, 21 Jul 1997 00:47:27 -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 AAA00376; Mon, 21 Jul 1997 00:47:22 -0700 (PDT) Message-Id: <199707210747.AAA00376@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) cc: multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-reply-to: Your message of "Mon, 21 Jul 1997 06:53:52 +0200." <199707210453.GAA13291@elch.heim4.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 00:47:22 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, You can issue SNDCTL_DSP_SYNC to flush the buffer as for the buffer size you can probably use 1/5 second you can compute the block size based upon the frequency. With respect to not getting back on time thats a function of how much cpu time its spend doing other things. You will have more than 1/5 second to get back to the driver because the driver queues up N buffer requests. You can figured out how many buffers are outstanding by issuing : 1. SNDCTL_DSP_GETOSPACE --- count_info info; ioctl(fd, SNDCTL_DSP_GETOPTR, &info); --- info.blocks == to the number of outstanding buffers. You can stop instantly by issuing a : SNDCTL_DSP_RESET Since that does an abrupt halt I suggest that you mute the volume and after the SNDCTL_DSP_RESET you can restore the volume ---- Hope this helps, Amancio >From The Desk Of Oliver Fromme : > > Hello, > > Just a small comment/question... > > Amancio Hasty wrote: > > [...] > > SNDCTL_DSP_SETFRAGMENT > > sets the block of io which the sub modules use to send or receive > > data. > > > > SNDCTL_DSP_SETBLKSIZE > > for all practical purposes is the same as the above. > > > > If the user does not set the block size then the dma routines choses > > a size equal to about 1/2 second worth of data. For typical sun > > style au files this is 4096 bytes . > > I am currently facing the following problem: I am writing a > frontend for mpg123 (MPEG audio player). When the user > presses the Pause/Stop button (or Fast Forward or whatever), > there's always a small delay -- I guess it is because of that > 1/2 second DMA buffer. However, I'd like the audio to stop > _immediately_ when a button is pressed, not 1/2 second later > or something like that. > > There are probably two solutions: > > - Using one of the above ioctls to reduce the buffer block > size (about 1/10 or maybe 1/5 second would be acceptable). > However, that probably increases the risk that the audio > playback is interrupted because the buffer can't be filled > in time by the application. This might especially be a > problem on slower CPUs, and/or if several other processes > are running in parallel. > > - Tell the audio device somehow to stop playback, and (in case > of Fast Forward) forget the rest of the buffered data. (In > the latter case, it would be an additional bonus if the > audio device could tell the application how much data was > discarded.) -- However, as far as I know, this isn't > possible, is it? > > Any suggestions and helpful hints are greatly appreciated. > > Regards > Oliver > > PS: On Solaris, I solved the problem like this: By doing a > write() with 0 bytes, a special "mark" is inserted in the > buffer. When the playback has reached that mark, a signal > (SIGPOLL) is delivered to the process, so we know how much data > has been actually played. Furthermore, the device supports > "pausing" by setting a flag (AUDIO_SETINFO ioctl), and it can > flush the remaining audio data from its buffer (I_FLUSH STREAMS > ioctl). > > -- > Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de)