[linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit

[Roger Larsson]

On Tuesday 02 December 2003 05.16, Paul Davis wrote:
> >On Monday 01 December 2003 20.48, Paul Davis wrote:
> >> i'd appreciate test reports ASAP, so that out trusty release
> >> technician (the very wonderful taybin rutkin) can get a new release
> >> out in the near future.
> >
> >alsa_driver.c
> >
> >	driver->period_usecs =3D
> >		(jack_time_t) floor ((((float) driver->frames_per_cycle) /
> >				      driver->frame_rate) * 1000000.0f);
> >
> >jackd/engine.c
> >	poll_timeout =3D (engine->control->real_time =3D=3D 0 ?
> >			engine->client_timeout_msecs :
> >			engine->driver->period_usecs/1000);
> >
> >	- - -
> >
> >	if (poll (pfd, 1, poll_timeout) < 0) {
> >
> >Isn't this dangerous?
> >* What happens if period_usecs < 1000?
> >  Well poll_timeout gets 0 since period_usecs is an uint64_t
> >  A poll with time out of zero will return immediately.
> >  OK?
>
> well, there is no alternative really. the kernel has no time
> resolution less than 1msec even on modern kernels with HZ=1000. so
> setting it lower could be rather risky, given the use of busywaits for
> some other SCHED_FIFO delays (see the code for usleep).
>
> but yes, you are right, it is dangerous. we should probably sleep for
> max (1msec, period_msecs). agree?

Either that or (period_msecs + 1)
You should get a solid lockup if your period_msecs is lower than 1000 us ==
 1 ms when running SCHED_FIFO... (unless you run clients at the same
priority and the kernel yields at poll - I don't think it does)

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden