>> well, if there are > 2 threads, one only polling and others doing
>> management work -- and this is probably the most useful approach to low-
>> latency PCM IO -- it is imaginable that a non-polling thread starts and
>> stops the device.
>
>In this case pthread_cond_wait and pthread_cond_signal
Tim Goetze wrote:
>
> Today Abramo Bagnara wrote:
>
> >Paul Davis wrote:
> >>
> >> >Don't make this mistake: poll *have* to return immediately in *all*
> >> >cases where to wait is useless (i.e. when no non-user driven event may
> >> >happen).
> >> >
> >> >This is the rule you need to remember.
Today Abramo Bagnara wrote:
>Paul Davis wrote:
>>
>> >Don't make this mistake: poll *have* to return immediately in *all*
>> >cases where to wait is useless (i.e. when no non-user driven event may
>> >happen).
>> >
>> >This is the rule you need to remember.
>>
>> where does this rule come from?
Paul Davis wrote:
>
> >Don't make this mistake: poll *have* to return immediately in *all*
> >cases where to wait is useless (i.e. when no non-user driven event may
> >happen).
> >
> >This is the rule you need to remember.
>
> where does this rule come from? i was under the impression that
> pol
>Don't make this mistake: poll *have* to return immediately in *all*
>cases where to wait is useless (i.e. when no non-user driven event may
>happen).
>
>This is the rule you need to remember.
where does this rule come from? i was under the impression that
poll(2) should timeout in those cases, n
On Sun, 2 Dec 2001, Tim Goetze wrote:
> On Dec 1 Abramo Bagnara wrote:
>
> >Tim Goetze wrote:
> >>
> >> Abramo Bagnara wrote:
> >>
> >> >Don't make this mistake: poll *have* to return immediately in *all*
> >> >cases where to wait is useless (i.e. when no non-user driven event may
> >> >happen).
On Dec 1 Abramo Bagnara wrote:
>Tim Goetze wrote:
>>
>> Abramo Bagnara wrote:
>>
>> >Don't make this mistake: poll *have* to return immediately in *all*
>> >cases where to wait is useless (i.e. when no non-user driven event may
>> >happen).
>> >
>> >This is the rule you need to remember.
>>
>>
Tim Goetze wrote:
>
> Abramo Bagnara wrote:
>
> >Don't make this mistake: poll *have* to return immediately in *all*
> >cases where to wait is useless (i.e. when no non-user driven event may
> >happen).
> >
> >This is the rule you need to remember.
>
> ok. here's a rule simple enough for me to
Abramo Bagnara wrote:
>Don't make this mistake: poll *have* to return immediately in *all*
>cases where to wait is useless (i.e. when no non-user driven event may
>happen).
>
>This is the rule you need to remember.
ok. here's a rule simple enough for me to remember :) but should poll in
this cas
Tim Goetze wrote:
>
> and another related problem: when i poll any stream before it is started,
> poll() returns immediately, too. while one may in an esoteric mood argue
> that this makes sense in the playback case since the stream *is* ready for
> data, this behaviour is nonsense with a capture
[with fresh alsa-cvs update]
i'm doing mmap'ed io on the audiophile (ice1712) with:
hw_params->period_size = 2048
sw_params->avail_min = 1024
as long as i use only one stream, i get 2048 available frames when
poll() returns. 1024 would be nicer, but it's workable like this, too.
as soon as i
11 matches
Mail list logo
