Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: vdr 1.3.18 cCondWait::SleepMs
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
Home |
Main Index |
Thread Index