Date: Wed, 03 Dec 1997 01:24:36 -0800 From: Tristan Savatier <tristan@mpegtv.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: race@exchange.lancs.ac.uk, multimedia@freebsd.org, hannu@opensound.com Subject: Re: MpegTV Problems Message-ID: <34852554.4B7E24DF@mpegtv.com> References: <199712030740.IAA17761@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > > 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. I'd love to have an ioctl that would return this type of precise information regardless of the fragment size. If such an ioctl was available (and I could know about it with SNDCTL_DSP_GETCAPS), I would use it rather than relying on GETOSPACE. This way I would not have to set such a small fragsize and the audio driver would waste less interrupt time. However, I still probably want more than two fragments, to better use the available driver's memory. Just two fragments of 32K means that possibly up to 32K of memory are unavailable, i.e. one fragment that is not completely drained by the dma. That may cause the audio driver to drain and starve too easiely. But fragments of say 4K or 8K would be OK. > But of course > to remain OSS compatible you have to set a small fragment size. Well, it is easy for me to remain OSS compatible while using better API's. as long as there is a way to test if the new API is available. > > 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... Actually lipsync is acceptable up to +- 1 or 2 video frames (1 frame is 1/30th of a sec). The problem is that the video rate control may introduce jitters of about +- 1 frame, so inaccuracy in the delay add to that. With OSS I found that setting fragsize to 1K in the case of 16-bit mono at 22 KHz (i.e. 1 frag = 1/43th of a sec) is a good compromise between accuracy and efficiency. A smaller fragsize would increase delay accuracy but would cause the audio driver to consume more CPU. Really, the good solution would be an ioctl to access to the number of bytes in the driver's fifo that is not linked to the frag size, if that is possible. Are all the audio hardware boards capable of letting you read the dma registers during a dma ? > luigi -- Regards, -- Tristan Savatier (President, MpegTV LLC) MpegTV: http://www.mpegtv.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34852554.4B7E24DF>