Date: Tue, 02 Dec 1997 20:29:53 -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 Savolainen <hannu@opensound.com> Subject: Re: MpegTV Problems Message-ID: <3484E041.413E8883@mpegtv.com> References: <199712030153.CAA17359@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > > > mtv: audio: audioioctl.c:98: near byte 0x0: ioctl(8, > > > SNDCTL_DSP_SETFRAGMENT, (8323082=0x7f000a) -> (8323082=0x7f000a)) = 0 > > [snip] > > > mtv: audio: audioioctl.c:102: near byte 0x0: ioctl(8, > > > SNDCTL_DSP_GETOSPACE, ...) = 0> mtv: audio: audioioctl.c:102: near byte 0x0: ioctl(8, > > > SNDCTL_DSP_GETOSPACE, ...) = 0 > > > mtv: audio: audioioctl.c:560: near byte 0x0: fragment size = 11024 > > ^^^^^ > > > mtv: audio: audioioctl.c:561: near byte 0x0: number of fragments = 5 > > > > That is odd! > > > > The software sets the frag size to 1024 with the SNDCTL_DSP_SETFRAGMENT. > > > > Why does it indicate 11024 ??? > > because my driver currently ignores SNDCTL_DSP_SETFRAGMENT and sets > the block size to 0.25s by default. To set the blocksize only, > one should use the SNDCTL_DSP_SETBLKSIZE call (or AIOSIZE which is > specific of my driver). > > I am not very fond of the FRAGMENT stuff, because it causes applications > depend too much on the amount of buffering in the kernel. I admit that > it has its uses, e.g. in many cases > people define a small amount of buffering (i.e. few small fragments) > and non-blocking mode to avoid that too much data is queued in the > driver. [However this does not seem to be the case here, as 127 > fragments are requested.] > It is impossible to properly synchronize audio and video without a way to get accurate delay information in the audio driver. 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. If those two ioctl are not supported or do not work, the MpegTV Player (mtv) will not work properly. It was suggested that a new ioctl could be added that would return the number of bytes in the driver's fifo. Ideally that's what is needed to compute the delay (assuming that there is no additionnal delay in some filter or mixer at the output of the driver. But currently such a ioctl is not available in OSS. > Unfortunately the above method is a bit cryptic and not clearly > documented. I have seen several apps which do not check for short > writes() resulting from the use of few fragments and non-blocking > I/O, with the result of producing plain noise in the audio output, > or having results which depend on the speed of the system. The size of buffers that are passed to write() should have nothing to do with the fragment size. If the driver cannot store the bytes immediately, the write should block until more fragments are available. > To support a similar functionality (avoid too much data queued) in > my opinion it would be preferable to have a call which tells you > how much data is queued, and then decide how much to write. > SNDCTL_DSP_GETOSPACE (or also AIONWRITE in my driver) tell you > something similar if you know how much buffer space is available > in the kernel. 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, which may represent more than say 1/30th of a second. This would not be acceptable for lipsync. > In any case it will not be hard to implement full fragment support in > my driver, and i will do it as soon as I have the time. (which i am > afraid will probably mean christmas). > > BTW: just yesterday I tried the BSDI version on a 2.2.1 machine with my > audio driver, and it seems to work smoothly. I cannot tell if there was > lipsync or so because the demo I played (from sony) had a train moving > and background sound, but it seemed to play to completion on both audio > and video. > Is there a difference in how the audio API is used in the linux and > BSDI version ? No, there is no difference. In order to check lipsync, try ftp://ftp.mpegtv.com/pub/mpeg/mpegtv/private/nf080969.mpg (the directory is protected and you cannot do ls, but the file is available). > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ -- Regards, -- Tristan Savatier (President, MpegTV LLC) MpegTV: http://www.mpegtv.com MPEG.ORG: http://www.mpeg.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3484E041.413E8883>