From owner-freebsd-multimedia Wed Dec 3 00:42:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21425 for multimedia-outgoing; Wed, 3 Dec 1997 00:42:54 -0800 (PST) (envelope-from owner-freebsd-multimedia) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA21413 for ; Wed, 3 Dec 1997 00:42:49 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA17761; Wed, 3 Dec 1997 08:40:02 +0100 From: Luigi Rizzo Message-Id: <199712030740.IAA17761@labinfo.iet.unipi.it> Subject: Re: MpegTV Problems To: tristan@mpegtv.com (Tristan Savatier) Date: Wed, 3 Dec 1997 08:40:02 +0100 (MET) Cc: race@exchange.lancs.ac.uk, multimedia@freebsd.org, hannu@opensound.com In-Reply-To: <3484E041.413E8883@mpegtv.com> from "Tristan Savatier" at Dec 2, 97 08:29:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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