1 Dec
2003
1 Dec
'03
9:12 p.m.
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 =
(jack_time_t) floor ((((float) driver->frames_per_cycle) /
driver->frame_rate) * 1000000.0f);
jackd/engine.c
poll_timeout = (engine->control->real_time == 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?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
2 Dec
2 Dec
12:18 a.m.
New subject: [linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit
On Monday 01 December 2003 20.48, Paul Davis wrote:
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?
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? 
1:11 a.m.
New subject: [linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit
Paul Davis <paul(a)linuxaudiosystems.com> writes:
but yes, you are right, it is dangerous. we should
probably sleep for
max (1msec, period_msecs). agree?
I agree.
Since the exact duration of the timeout probably doesn't matter that
much, I am experiementing with just adding one to period_msecs.
--
joq
3:45 a.m.
New subject: [linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit
On Tuesday 02 December 2003 05.16, Paul Davis wrote:
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
On Monday 01
December 2003 20.48, Paul Davis wrote:
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? 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?
7615
days inactive
7616
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Jack O'Quin -
Paul Davis -
Roger Larsson