[vdr] Re: vdr 1.3.18 cCondWait::SleepMs

[Ludwig Nussel <ludwig.nussel@gmx.de>]

Klaus Schmidinger wrote:
> Ok, let's take a closer look at all SleepMs() places:
> [...]
> dvbdevice.c-{
> dvbdevice.c-  if (digitalAudio != On) {
> dvbdevice.c-     if (digitalAudio)
> dvbdevice.c:        cCondWait::SleepMs(1000); // Wait until any leftover 
> digital data has been flushed
> dvbdevice.c-     SetVolumeDevice(On || IsMute() ? 0 : CurrentVolume());
> dvbdevice.c-     digitalAudio = On;
> dvbdevice.c-     }
> 
> --> When switching from digital to analog output there is typically still
>     some leftover data somewhere in the buffers, but there's no way to find
>     out when all these buffers are actually empty - or is there? So we wait
>     one second, which is apparently enough to have the buffers flushed.
>     Try removing this to hear the chirping sound it makes.

=> workaround for broken driver

> dvbdevice.c-#define MIN_IFRAME 400000
> dvbdevice.c-  for (int i = MIN_IFRAME / Length + 1; i > 0; i--) {
> dvbdevice.c-      safe_write(fd_video, Data, Length);
> dvbdevice.c:      cCondWait::SleepMs(3); // allows the buffer to be 
> displayed in case the progress display is active
> dvbdevice.c-      }
> dvbdevice.c-#endif
> dvbdevice.c-}
> 
> --> For some reason, displaying a still image only works with this sleep. 
> Again,
>     there's nothing we could reasonably wait for.

=> workaround for broken driver.

> [...]
> sections.c-        if (poll(pfd, NumFilters, 1000) > 0) {
> sections.c-           bool DeviceHasLock = device->HasLock();
> sections.c-           if (!DeviceHasLock)
> sections.c:              cCondWait::SleepMs(100);
> sections.c-           for (int i = 0; i < NumFilters; i++) {
> sections.c-               if (pfd[i].revents & POLLIN) {
> sections.c-                  cFilterHandle *fh = NULL;
> 
> --> Here we just wait a little in case the device doesn't have a lock, yet.
>     This should only happed rarely, so no big waste here. Maybe the sleep
>     could be dropped altogether, since there is a poll() just before it.

Further down there is 
int r = safe_read(fh->handle, buf, sizeof(buf));
if (!DeviceHasLock)
	continue; // we do the read anyway, to flush any data that might have come from a different transponder

> [...]
> transfer.c-           //XXX audio with the video frames. 2004/09/09 Werner
> transfer.c-           if (!GotBufferReserve) {
> transfer.c-              if (ringBuffer->Available() < 3 * MAXFRAMESIZE / 
> 2) {
> transfer.c:                 cCondWait::SleepMs(20); // allow the buffer to 
> collect some reserve
> transfer.c-                 continue;
> transfer.c-                 }
> transfer.c-              else
> 
> --> This just gives the ring buffer a chance to fill up, which only happens
>     at the beginning of a Transfer Mode, so no big deal in normal operation.

Wouldn't it be sufficient to block on ringBuffer->Get()?

Anyways, the difference between those sleeps and the following is
that the latter one sleeps in a loop while holding a lock.

> dvbplayer.c-                    }
> dvbplayer.c-                 }
> dvbplayer.c-              else
> dvbplayer.c:                 cCondWait::SleepMs(3); // this keeps the CPU 
> load low
> dvbplayer.c-              }
> dvbplayer.c-
> dvbplayer.c-           // Store the frame in the buffer:
> 
> --> Finally, here's the only place where SleepMs() is used in "normal" 
> operation.
>     But then again, it's only in case of pause mode, and I really don't 
>     think that
>     it should hurt too much. As far as I understood the postings regarding 
>     sleeping,
>     only sleep times up to 2ms cause a busy wait, everything above will 
>     imediately
>     give up the time slice and wait non-busy.
>     @Ludwig: as Rainer already stated there is also the "running" flag to 
>     take
>     into account here, so I still believe it's ok to use SleepMs() here.

That's why I put another broadcast() into Activate().

cu
Ludwig

-- 
(o_  Ludwig.Nussel@gmx.de
//\
V_/_ PGP Key ID: FF8135CE