Date: Wed, 3 Dec 1997 12:58:40 +0200 (EET) From: Hannu Savolainen <hannu@opensound.com> To: Tristan Savatier <tristan@mpegtv.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, race@exchange.lancs.ac.uk, multimedia@freebsd.org Subject: Re: MpegTV Problems Message-ID: <Pine.LNX.3.95.971203124500.1311F-100000@janus.opensound.com> In-Reply-To: <348530A0.248965D0@mpegtv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.971203124500.1311F-100000>