[vdr] possible busy loop in cDvbPlayer::Action?

Martin Wache M.Wache at gmx.net
Sun Jul 3 10:34:46 CEST 2005

Stefan Lucke schrieb:
> On Samstag, 2. Juli 2005 13:21, Luca Olivetti wrote:
>>Martin Wache wrote:
>>>I thought about letting the softdevice sleep even when the buffers are
>>>not full, but I think the correct solution would be that vdr sleep in
>>>case it doesn't have some frames to send. Or did I get the Poll()
>>>function wrong? Should Poll() sleep in any case?
>>from device.h
>>   virtual bool Poll(cPoller &Poller, int TimeoutMs = 0);
>>        ///< Returns true if the device itself or any of the file handles in
>>        ///< Poller is ready for further action.
>>        ///< If TimeoutMs is not zero, the device will wait up to the 
>>given number
>>        ///< of milleseconds before returning in case there is no immediate
>>        ///< need for data.
> What about this interpretation:
> So the  question is when has the device an immediate need for data ?
> This is the case when the buffer of the device is empty. If this
> condition is met, the device has to ignore a given timeout and
> return immediate. If buffer empty condition is not satisfied,
> device has to sleep when timout is not zero.
I don't think that this the correct interpretation.
When the buffers are empty, we have a buffer underrun. We'll never get a
smooth playback if we let the buffers run empty.
If we define the immediate need for data different (maybe 1/3 of the
buffer filled) we will effectivly make the buffers smaller, since as
soon as we sleep after/before the reception of one packet we will reduce
the throughput to a level far below the consumption rate. The smallest
sensible sleep is about 3ms that means we will be able to transfer only
13 packets per frame (40ms). Usually a frame has more packets than 13,
so the buffer fill will soon drop below our immediate need for data limit.
No, the longer I think about it the more confident I get that the only
sensible solution is that vdr should sleep in case it doesn't have any data.


More information about the vdr mailing list