From owner-freebsd-multimedia Thu Jul 31 03:15:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA25280 for multimedia-outgoing; Thu, 31 Jul 1997 03:15:53 -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 DAA25274 for ; Thu, 31 Jul 1997 03:15:48 -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 DAA05463 for ; Thu, 31 Jul 1997 03:15:48 -0700 (PDT) Message-Id: <199707311015.DAA05463@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: rplay and guspnp14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jul 1997 03:15:47 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, the problem that people may encountered with rplay and guspnp14 is that rplay uses SND_CTL_POST to flush the audio buffers which happens not to do that rather starts the dma processing . The dma routines at times can interleave audio buffers so in a way is a bug in the dma buffering algorithm ;however, in this case just by using SND_CTL_SYNC it fixes most of the problems. The last issue is that rplay upon start playback of a sound stream does not check to see if the buffers has been flushed . Yes, this is a dma buffering algorithm however in this case the application can compensate by first checking at the start of a sound stream if the buffers has been flushed. I will look into fixing the dma buffering algorithm however I rather not fixed it given that it is easy to fix in rplay and that the sound driver is currently being revamp by Luigi. If anyone wants to fix the dma buffering in guspnp14, I will be happy to guide them thru dmabuf. Cheers, Amancio