Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD

[Greg Troxel]

LRK <address@hidden> writes:

> Obviously it would be neat to extend ugen if the fixes were generic
> but if there need to be USRP-specific fixes they would best be done
> in a different module.

Agreed in genearl, but not that any USRP-specific changes are needed.

> Maybe I'm not understanding this but it looks to me like ugen just
> responds with a code saying it will take a device if no other driver
> wants it. A copy of ugen named usrp could respond only to being
> offered a USRP but the USRP should have a unique number assigned
> rather than the general one used now. If there was a driver unique
> to the USRP, it would not need to work with other USB devices, thus
> my suggesting that direction.

True, but then there's more forked code to maintain, which is a big
minus.

> It also seems that the USRP tx and rx paths normally use the same
> block size after each open. If that is right, the driver could
> simply use that block size until the stream is closed, reading ahead
> on rx and providing flow control on tx.

That'a s good point: write transactions need to be some speed,
controllable by the user.

> It appears the attempts to read the USRP at more than 4 MB/s just
> lock and transfer no data.

What system?  Could you be more precise?  On NetBSD one gets missing
data according to the test program (presumably due to overruns in the
on-USRP buffer because USB transactions don't happen fast enough).
But nothing else bad happens.

> Changing the 'read' in libusb to just return as though it had
> finished results in the 'test_usrp_standard_rx' giving similar
> results at all speeds including the pattern of overrun errors.

You mean if you change the code to just skip the reads?  I don't see
what you are trying to find out from this experiment.

>  The transfer rate calculated is very fast so the overrun error
> count seems to be a function of the USRP code rather than actual
> overruns.

I don't see how this follows.

-- 
        Greg Troxel <address@hidden>