Date: Wed, 03 Dec 1997 03:29:30 -0800 From: Tristan Savatier <tristan@mpegtv.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: Hannu Savolainen <hannu@opensound.com>, Luigi Rizzo <luigi@labinfo.iet.unipi.it>, race@exchange.lancs.ac.uk, multimedia@freebsd.org Subject: Re: MpegTV Problems Message-ID: <34854299.23C96466@mpegtv.com> References: <199712030951.KAA18023@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> The point I am trying to make there is that having multiple ways > to achieve the same result is a bad thing since it causes people > to mix them in the most peculiar ways. I agree. However, right now there is no good way to get access to the delay (i.e. the number of bytes in the driver's fifo that have not been yet been processed by the dma). The technique using GETOSPACE is a kludge which works reasonnably well (if the driver has a working GETOSPACE ioctl), but only gives the delay within a frag accuracy. The GETOPTR technique, if it was working well with all the drivers, would be OK too, even better in a way: it would be give me an accurate delay. It is just slightly more painfull to use because one has to keep track of the number of bytes written in order to derive the delay, plus this reset after one hour is another thing to deal with. But I can handle all that (I must, since that's the way I get the delay with the Sun driver) I am not totally convinced that we need yet another ioctl. Hannu has to decide. Really, for me the bigest problem is to not be able to know if the driver works properly (as advertised). I have to rely on the driver, but unfortunately those IOCTL that are important for MpegTV are broken on the vast majority of the drivers distributed with Linux (or not implemented in the case of freeBSD). -t
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34854299.23C96466>