[vdr] FF card AV sync problems, possible fix to VDR

[Oliver Endriss]

Klaus Schmidinger wrote:
> VDR User wrote:
> > On 1/31/07, *Klaus Schmidinger* <Klaus.Schmidinger at cadsoft.de
> > <mailto:Klaus.Schmidinger at cadsoft.de>> wrote:
> > 
> >     VDR User wrote:
> >     > From what he's saying, the problem is buffer overrun's, not
> >     underrun's.

Afaics this is just a guess. We need a sample recording and track down
what happens in the driver/firmware.

> >     > Too much data is being sent and the device isn't able to keep up.  If
> >     > that's the case then it would make sense for vdr to have a user
> >     setting
> >     > to limit how many seconds (or milliseconds perhaps?) worth of data is
> >     > sent to the buffer.  I can't think of any reason not to add such a
> >     > feature if it means better usability for the end-user.
> > 
> >     If the device can't take any more data, it should just refuse to
> >     accept it and return from the write() call without anything written.

Code from the driver:
|        ...
|        if (nonblock && !FREE_COND)
|                return -EWOULDBLOCK;
|
|        while (todo > 0) {
|                if (!FREE_COND) {
|                        if (nonblock)
|                                return count - todo;
|                        if (wait_event_interruptible(av7110->avout.queue,
|                                                     FREE_COND))
|                                return count - todo;
|                }
|         ...

Looks ok to me. The driver does not accept more data than it can handle.

> > I disagree.  Simply returning from write() implies the data was written
> > and the device is ready for more.
> 
> The write() function returns the number of bytes actually written,
> which is not necessarily the same as the number of bytes the caller
> wanted to write. So the device can chose not to accept all of the data.
> If the device is currently unable to accept any data (and the file handle
> is in O_NONBLOCK mode) it shall return EAGAIN to inform the caller that
> it is currently busy and that the caller should try again later.
> 
> >  If this is not true then you risk
> > making the sync even worse.  I consulted with people familiar with this
> > type of stuff and it was suggested the problem could (and should) be
> > fixed at the driver level so I'm following up on that now.
> 
> Well, that's exactly what I was suggesting. The write() function has
> everything it takes to block data from coming into the device if its
> buffer is full. No need for the caller to do any funny estimates here.

Fullack. There is no reason to add workarounds like this to VDR.

@all:
Don't panic. Provide samples. :-)

Oliver

-- 
--------------------------------------------------------
VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------