From owner-freebsd-multimedia Wed Dec 3 02:55:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29103 for multimedia-outgoing; Wed, 3 Dec 1997 02:55:41 -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 CAA29092 for ; Wed, 3 Dec 1997 02:55:37 -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 MAA20963; Wed, 3 Dec 1997 12:55:25 +0200 (EET) Received: from localhost (hannu@localhost) by janus.opensound.com (8.8.5/8.8.5) with SMTP id MAA01556; Wed, 3 Dec 1997 12:58:40 +0200 Date: Wed, 3 Dec 1997 12:58:40 +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: <348530A0.248965D0@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: > > > > On Wed, 3 Dec 1997, Tristan Savatier wrote: > > > > > I'd love to have an ioctl that would return this type of precise > > > information regardless of the fragment size. > > I will implement this call in few days. I just need to find a good > > descriptive name for it. It will be included in the commercial OSS 3.8.1 > > version as well as OSS/Free 3.8s3. > > Well, I am still not sure that I understand how the information > returned by this call would be different from the > info.bytes returned by GETOSPACE (when GETOSPACE works). The info.bytes of GETOSPACE tells only how much _empty space_ is ahead you. If you write info.bytes or less data to the device immediately after calling GETOSPACE the application will not block. But if you write info.bytes+1 or more data the application will block until a new buffer fragment becomes free. The new ioctl (possibly SNDCTL_DSP_GETODELAY) tells the opposite. It will return the number of unplayed bytes before the location where the next byte you write would be copied. In theory these calls return redundant information. So it would be assumed that the value returned by GETODELAY is the same than (info.frastotal*info.fragsize)-info.bytes. However this is NOT true since some of the otherwise "empty" space is not writeable. 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)