LRK <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
