[vdr] Re: [ANNOUNCE] vdr-softdevice-0.0.7pre2

[Guido Fiala <gfiala@s.netic.de>]

Mmm, if it doesn't work using the thread the question is exactly why - is it a 
buffer over/underrun in hardware or software and where?
Is it a priority problem?
Depending on the answers one might to play with one or more parameters - 
increase priority (threads reading the hardware-buffer need a higher priority 
than others in the data chain), increase buffers (if its just timing) or if 
not possible increase HZ. (100Hz means 10ms scheduling, 1000HZ means 1ms 
scheduling).
If more precisision is required maybe the thing has to be put into an 
interrupt handler?

Guido

On Saturday 07 August 2004 14:16, Stefan Lucke wrote:
> On Donnerstag, 5. August 2004 12:37, Dr. Werner Fink wrote:
> [ .. ]
>
> >        As some applications  require  much  more  precise  pauses
> >        (e.g.,  in  order to control some time-critical hardware),
> >        nanosleep is also capable of short high-precision  pauses.
> >        If  the process is scheduled under a real-time policy like
> >        SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will  be
> >        performed as busy waits with microsecond precision.
> >
> > ...
> >
> > In other words ... usleep(1 ... 2000) do _not_ trigger the scheduler
> > to get other thread/processes at work, for this a simple sched_yield(2)
> > or pthread_yield(no man page) should be used.
>
> NO. I played around the usleep(1) in vd1.3.12 transfer.c line 127.
> Using (kernel 2.4.27-pre5):
>  phtread_yield() -> cpu 100%
>  sched_yield() -> stream corrupted, every now and then some single blocks
> decoded. usleep(1) -> live stream plays fine.
>
> So if "usleep(1)" is bad, it should be replaced by something other not yet
> mentioned.
>
>
> Stefan Lucke