From owner-freebsd-multimedia Wed Dec 3 02:40:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA28341 for multimedia-outgoing; Wed, 3 Dec 1997 02:40:49 -0800 (PST) (envelope-from owner-freebsd-multimedia) Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA28336 for ; Wed, 3 Dec 1997 02:40:46 -0800 (PST) (envelope-from hannu@opensound.com) Received: from janus.opensound.com (janus.opensound.com [193.94.53.108]) by lassie.eunet.fi (8.8.7/8.8.3) with ESMTP id MAA19030; Wed, 3 Dec 1997 12:40:43 +0200 (EET) Received: from localhost (hannu@localhost) by janus.opensound.com (8.8.5/8.8.5) with SMTP id MAA01509; Wed, 3 Dec 1997 12:44:10 +0200 Date: Wed, 3 Dec 1997 12:44:10 +0200 (EET) From: Hannu Savolainen To: Tristan Savatier cc: Luigi Rizzo , race@exchange.lancs.ac.uk, multimedia@freebsd.org Subject: Re: MpegTV Problems In-Reply-To: <3485275C.162985BB@mpegtv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 3 Dec 1997, Tristan Savatier wrote: > Hannu Savolainen wrote: > > > > Hi, > > > > The info.ptr value returned by OSS is computed from the DMA residue count. > > However the old VoxWare driver for FreeBSD doesn't work in this way. > > Instead it works just on the fragment boundaries. > > Do you mean info.ptr == number of bytes currently in the driver's fifo ? > I thought that was info.bytes ? I'm talking about SNDCTL_DSP_GETOPTR. It doesn't return return number of bytes in the buffer directly in any field but just a "pointer" to the byte being currently accessed by the hardware. info.ptr is the pointer relative to the beginning of the kernel level DMA buffer (only usable when using mmap()). info.bytes is the pointer to the current byte counted from the first byte written to the device since open() or previous call to SNDCTL_DSP_RESET (with wrapping to 0 after each hour). SNDCTL_DSP_GETOSPACE's (only) purpose is to return the number of that can be written without blocking. It always works in fragment boundaries since OSS doesn't allow writing anything to the fragment being currently processed by the hardware. > The problem is that it is hard for me to decide automatically > which method will work better (if any), and whether > it is necessary to set a small fragsize or not (since > in theory, if GETOPTR works as advertised, I should > not have to set a small fragsize if using the GETOPTR > method. In any case it's recommended to use relatively short fragment size in real time applications. However there would be some performance penalties if you go below (say) 1/50th of second. Best regards, Hannu ----- Hannu Savolainen (hannu@opensound.com) http://www.fi.opensound.com/~hannu (personal) http://www.opensound.com/oss.html (Open Sound System (OSS)) http://www.opensound.com/ossfree (OSS Free/TASD/VoxWare)