Date: Wed, 3 Dec 1997 08:40:02 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: tristan@mpegtv.com (Tristan Savatier) Cc: race@exchange.lancs.ac.uk, multimedia@freebsd.org, hannu@opensound.com Subject: Re: MpegTV Problems Message-ID: <199712030740.IAA17761@labinfo.iet.unipi.it> In-Reply-To: <3484E041.413E8883@mpegtv.com> from "Tristan Savatier" at Dec 2, 97 08:29:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> With the OSS driver, currently the only way to > get accurate delay information is to set the fragment size > to a relatively small size, and to use GETOSPACE. ... > I still have to set the fragment size to small, otherwise > the information about the data queued would be very inaccurate. > My understanding is that the driver is called on interrupt > to setup dma for a fragment. If the fragment is large and > there is no way to know the current status of a dma transfer > in process, then the accuracy is limited to one fragment, right. In my driver, and i guess amancio has done something similar, whenever some ioctl() is invoked which needs to know the status of the transfer, i read the transfer count from the dma registers, so i have a precise information independent of the fragment size. But of course to remain OSS compatible you have to set a small fragment size. > which may represent more than say 1/30th of a second. This > would not be acceptable for lipsync. actually i am not sure on what is really the maximum acceptable delay for lipsync (or maybe it is also the jitter which counts). 30ms (which is the refresh rate of a tv) correspond to the delay between audio and video when you look at someone speaking at a distance of about 10m. i guess we are used to such delays... luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712030740.IAA17761>