Date: Thu, 04 Dec 1997 01:45:26 -0800 From: Tristan Savatier <tristan@mpegtv.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: Hannu Savolainen <hannu@opensound.com>, multimedia@freebsd.org Subject: Re: MpegTV Problems Message-ID: <34867BB6.7A38C555@mpegtv.com> References: <199712040747.IAA20138@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > [snip] > > Well I may be wrong but I am pretty sure of what I saw. no, you appear to be correct... This is deffinitely incorrect. It should be blocking. I looked at my code and found that yes, the device is opened with O_NONBLOCK, which is probably not necessary when I am using OSS. Note: The reason why I had O_NONBLOCK when opening the device was reminiscent from the Sun audio driver. With sun audio, the behavior of open() is changed depending of O_NONBLOCK. Is O_NONBLOCK is not set, open() blocks until the audio device becomes available. Otherwise, open() returns immediately, with an error if the device is in use. I don't think OSS open() works this way, does it ? After opening the device with O_NONBLOCK, mtvp resets the O_NONBLOCK flag with fcntl().... except in the case of the BSD/OS version!! (you are using this version, aren't you ?). Unfortunately I forgot to put a comment explaining why, but I am quite sure that it's because there was a problem reseting O_NONBLOCK with the BSD/OS version of the driver. I will have to look at that, and maybe to change and open without O_NONBLOCK when I use OSS. [snip] > > Non blocking I/O and write queue full suggests that the program is > looping around a write() to the audio device trying to complete > it. For sure it can never sleeps on that write(). that's probably what's happening. -t Luigi Rizzo wrote: > > > You must have misread. The process that uses the most > > CPU (the video decoder) also uses the most memory: > > > > PID USER PRI NI SIZE RES SHRD STAT %CPU %MEM TIME COMMAND > > 420 tristan 15 0 5484 3076 908 R 71.0 6.5 0:40 ././mtvp -W0 > > -w-1 -a > > 421 tristan 2 0 4632 888 492 S 7.9 1.8 0:05 ././mtvp -W0 > > -w-1 -a > > > > > Looking further in depth, I notice you use the audio device in > > > non-blocking mode. > > > > You mean blocking mode. The audio process blocks if there > > is not enough room to write a decoded audio frame in the audio > > driver. > > Well I may be wrong but I am pretty sure of what I saw. I'll give > you full details in the hope you can reproduce these results yourself > (OS version and hardware type should not really matter much, and > while some things are peculiar of my audio driver i suspect the > non-blocking mode problem also appears with Voxware). > > OS: FreeBSD 2.2.1 with my audio driver; any 2.2.X or 3.X should > give the same behaviour. > > hardware: Pentium 133 with 32MB, S3-765 video card with 2MB ram, > used in 16-bit depth at 1024x868. > > mtv: BSD/386 version > -rwxrwxr-x 1 luigi wheel 724992 Nov 27 10:20 mtv > -rwxrwxr-x 1 luigi wheel 811064 Nov 27 10:20 mtvp > > mpg file: a file called gen140.mpg from Sony (I'll put it on my > web page http://www.iet.unipi.it/~luigi/gen140.mpg) but I saw > the same behaviour with the lipsync example you mentioned. > > Tools used: "top" to check memory and cpu usage, plus a small program > called "test" (distributed with my sound driver) to look at > what happens to the audio driver. "test" mmaps the audio > device descriptors, and dumps its content every second. > Among the info you can see there are the flags, blocksize, > and the occupancy status of the play and record queues. > > So I start mtv playing the file continuously, and run top and test > in two separate windows. After several seconds of running top more or > less stabilizes on the following output: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 230 luigi 73 0 3668K 552K RUN 0:27 37.18% 36.62% mtvp > 190 luigi 2 0 3180K 3164K select 0:13 14.53% 14.53% XF86_S3 > 229 luigi 2 0 4340K 2208K select 0:07 10.30% 10.15% mtvp > > So you see that the small memory consumer is the process taking most > of the CPU. I assume it is the audio decoder, but I may be wrong. > > At the same time, the "test" window shows the following: > > prova# ~/test 1 > open returns 3 > mmap: w 0x08090000, r 0x080a0000, d 0x0801a000 > device type 10 name OPTi931 > flags... fmt speed .bsz. c in-rl:in-dl:in-fl.ints c ou-fl:ou_dl:ou-rl.ints | > 20000201 10 22050 11024 6 0 0 65280 0 1 768 11024 64512 254 | > 20000201 10 22050 11024 6 0 0 65280 0 1 0 11024 65280 258 | > > >From this I see that the device is used in 16-bit mode, 22050 hz, > and a blocksize of 11024 (because my driver currently ignores > SETFRAGMENT). The output queue, somewhat surprisingly, is completely > full (ou-rl = 65280 is the number of ready bytes in the queue, and > 65280 is the size of the whole queue). The flags field have the > following meaning (from /sys/i386/isa/snd/sound.h): > > #define SND_F_BUSY 0x0001 /* has been opened */ > #define SND_F_BUSY_DSP 0x20000000 > #define SND_F_NBIO 0x0200 /* do non-blocking i/o */ > > so, somehow the driver has been instructed to do non-blocking I/O. > This can be either in the open() call, or using some ioctl like > SNDCTL_DSP_NONBLOCK or FIONBIO. > > Non blocking I/O and write queue full suggests that the program is > looping around a write() to the audio device trying to complete > it. For sure it can never sleeps on that write(). > > Although the "queue full" situation might be triggered by my driver > ignoring the SETFRAGMENT, the non-blocking io must be in the source > somewhere. Maybe it is not something you wanted to do, but since > almost all audio programs for which I have seen source use the > audio device in non blocking mode, the call to FIONBIO might have > slipped in your code inadvertently. > > Hope this helps > 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/ > _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34867BB6.7A38C555>