St?phane Letz wrote:
>>
>> 1) The prefill means that you have to incur additional output latency
>> that you wouldn't otherwise need, using this approach (But you have
>> to prefill at least two fragments to avoid an underrun anyway. But
>> your approach requires *3* fragments, so even more latency. :-(
>>
>> 2) You have to size your buffers (256 bytes in your example) such
>> that you can't have underruns or overruns. You wind up having to
>> rely on a (probably reasonable, but I'm not entirely sure universally
>> true) behavior that the framework will never fall more than 2
>> fragments ahead or behind.
>>
>> The poll model I gave you totally disconnects your application's
>> natural processing chunk size (say 256 bytes) from whatever the
>> underlying kernel and driver uses. And, barring delays in
>> application processing, is completely free of overrun and underrun
>> conditions, as well as free of any potentially risky assumptions.
>>
>> I think you're trying to hard to avoid using poll(). If you want to
>> do duplex I/O (be it with an audio device, or a network service, or
>> anything else) where the I/O streams are independent and need to be
>> serviced in a timely fashion, you have only two choices to do so
>> correctly:
>>
>> 1) Use separate threads
>> 2) Use poll or select with either non-blocking IO or (for OSS only)
>> ioctls to ensure that your reads/writes don't wind up sleeping
>>
>> A third "incorrect" choice would be to:
>>
>> 3) Use non-blocking IO and busy waiting. (This would be an
>> incredibly bad choice, however.)
>>
>> Note that blocking I/O cannot be used with duplex I/O *if* you have
>> timing constraints to meet. (Such as underflow or overflow
>> conditions to be worried about.)
>>
>> -- Garrett
>
>
> So I think the "separate threads" would be the better for us:
> Read/Process in one thread (our Process operation does not takes time
> by itself but just signal real clients that input data is there..) and
> Write in a second thread. (I guess it is always better to avoid a lot
> of kernel/userland swiches that would occur more often in the poll
> model [ as each fragment boundary i guess] yes?)
This is indeed probably the simplest approach. You'd have to figure out
any synchronization (using locks, condvars, or whatever) issues that are
intrinsic to your application, but at least the code that interfaces
with the audio device/kernel would be vastly simpler.
-- Garrett
>
> Thanks
>
> Stephane Letz
