Date: Wed, 03 Dec 1997 03:18:04 -0800 From: Tristan Savatier <tristan@mpegtv.com> To: Hannu Savolainen <hannu@opensound.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, race@exchange.lancs.ac.uk, multimedia@freebsd.org Subject: Re: MpegTV Problems Message-ID: <34853FEC.62F6B889@mpegtv.com> References: <Pine.LNX.3.95.971203121331.1311E-100000@janus.opensound.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hannu Savolainen wrote:
>
> 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).
<linux/soundcard.h>:
typedef struct count_info {
int bytes; /* Total # of bytes processed */
int blocks; /* # of fragment transitions since last time */
int ptr; /* Current DMA pointer value */
} count_info;
Actually info.bytes is not a pointer, as you say.
It is the number of bytes
processed since the device was opened or reset (and it is
reset every hour, which is not documented and should be, imho).
In any case, I agree that what we need is
SNDCTL_DSP_GETUSED (or whatever other name)
that should return the number of bytes
in the driver's fifo (possibly 0 if drained), and -1 if the
ioctl is not implemented.
> 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.
I understand that. I know that the way I use SNDCTL_DSP_GETOSPACE
is not the way it was intended to be used, but until now
that was the only was for me to get the delay.
-t
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34853FEC.62F6B889>