> > 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?) Thanks Stephane Letz
