> > > > Jan> On Thu, Oct 17, 2002 at 03:39:21PM +0300, Momchil Velikov wrote: > > Nagaraj> for( buff_index = i = 0; i < xfer_count; i++, buff_index = > > Nagaraj> (buff_index+1)%MAX_BUFFERS ) { > > >> > > Nagaraj> sleep(1000); > > >> > > Nagaraj> read( buff_fd, (mbuff +buff_index*BUFF_SIZE), BUFF_SIZE ); > > >> > > Nagaraj> } > > >> > > >> First, the above code has a race condition, which can add up to 1000 sec (!) > > >> latency per frame! > > > > Jan> Yes, there is. But first, it skips only to the next frame and > > > > I wouldn't call 1000 seconds "only". > > > > But, yes, not per frame, but per xfer_count frames. > > No. You still don't seem to realize, that a signal is emited each time > one buffer is completed. And as the buffer is at most one frame, signals > are sent at least at frame rate. That is some 1/18 or 1/25 second period > or something like that. And that is actually the upper bound for time > the sleep can sleep. I hope I have the right to call 1/18 second "only". > Hey waiittt... The BUFF_SIZE = 128k , not the FrameSize as u r talking. This size is there bcoz i cant get more with any other calls. Signal will be there for 128k of xfer, its independent of any other params such as frame size, and others. The thing is that, driver never worries abt "whats there in the data". be it MPEG streams or some junk. And more over the device neednt be a network card, it could be a video card as well. So as a driver writer, i m worried only abt the bandwidth of xfer and buffer size. However, my code has holes when hardware changes, suppose the card supports 300Mbps and my current code works for 20Mbps. and i hv 10 buffers ( each 20Mbits ). Let the disk read take 1000ms for 1 buffer ( we hv very slow HD suppose ). Now, the device would xfer 1st buffer in 1/15 th of a sec. And second in next 1/15th. So even before 1st buffer is read from disk, all 10 buffers are consumed. Now u hv a problem, u'll get all signals during read() and none after it. so appl keeps waiting till timeout and display goes crazy. Thats why i told, u need to consider the hardwares when u decide upon the number of buffers and type of sync method u want. I think im not putting more crap here ... -nagaraj \(*_*)/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/