Iain Hibbert <plunky@rya-online.net> writes:

> With regards, to using isochronous transfers, one of your sticky points is
> no support for writing from userland..  There is code in pr/25960 that
> would enable this for ugen.

The lack of write support in ugen isn't the only difficulty with
using isochronous transfers.  The ehci driver does not implement
isochronous transfers at all, so that would have to addressed in
addition to using the code from the PR.  Also, for the USRP (and
potentially other devices), the error correction provided by bulk
transfers is considered a benefit over isochronous transfers.

> In your "Implementation Approaches", I see no mention of mmap() and
> circular buffers, as used in audio(4)/audio(9). I dont know how well this
> could fit with libusb, but did you consider that method?

I see that when using mmap() with the audio driver, the driver reads
continuously into the buffer even if the data is not being consumed
fast enough by user space (discarding old data) and writes zeros if
data is not being written fast enough.  This makes sense for audio,
and perhaps you were thinking there would a different behavior for
mmapped buffers in ugen, but I don't think we want to force users of
continuous read mode to keep up or risk losing data.  Even if ugen
doesn't discard data when the read buffer fills, bulk transfers
aren't guaranteed to happen in a timely manner, so I believe userland
can't assume that data was transferred and would have to query the
buffer state a lot to avoid reading extraneous "zeros" or overwriting
data.

Keeping the usual read and write semantics and adding buffering is a
simpler interface change and makes more sense to us to use for the
kind of data represented by the USRP.  Since you mention libusb, a
special mode for dealing with circular buffers would definitely have
to be added.  That said, continuous read mode doesn't preclude
addition of mmap() to access the buffers.

Joanne