[hpsdr] Starter question

[Eric Blossom]

On Wed, Nov 15, 2006 at 02:29:40PM -0000, Bob Cowdery wrote:
> 
> > It would probably be better to set up a user mode server process that
> > handles access to the OZY USB device that other processes can connect
> > to.
> >
> > I think it is a mistake to try to make OZY look like a sound card to
> > the system.  Right now we enjoy very low latency and overhead in
> > talking to the OZY via USB.  Making OZY appear as a sound card puts
> > more latency and overhead crud on top of what we have now.
> >
> > Phil N8VB
> >   
> I don't know about windows, but for Linux having separate USB endpoints 
> for audio and control would be considerably easier to deal with.

I think either of these approaches is technically feasible.  Right now
with the current USRP firmware + host code we use 3 endpoints, ep0 for
control and status, ep2 for streaming Tx samples and ep6 for streaming
Rx samples.  ep0 can be opened by multiple processes, so that part
works OK.  ep2 and ep6 may each be opened by the same or a different
processes, but only a single open per endpoint.

That said, I'm going to be changing the host+firmware such that
control/status is passed "in-band" with the data.  Part of the problem
with the existing setup is that control messages on ep0 are sent
across the USB at higher priority than the data messages.  This means
that it's pretty much impossible to figure out when a control message
has actually taken place with regard to the flow of samples to/from
the device.

This makes it hard to write host code that for example scans the front
end across a wide band, since it's pretty much indeterminate as to
when the "new samples" start coming.  The kludge is to wait "a while",
but this kills your scanning rate.

With "in-band signaling" you can provide a "host cookie" with the the
tune command.  The host cookie could be a monotonically increasing
value that is stored in the FPGA and then copied into the outgoing
data headers.  You'll still need to account for time required for the
front end PLL (if any) to settle, etc., but the temporal ambiguity of
command vs data will be resolved.  This will also allow pipelining of
control.

This then requires a "dispatcher" processes (or driver) to allow
multiple processes to open the virtual device, but I think this is
going to net out a win.

I'm hoping to have this coded up by January.

Eric, K7GNU

 1163611202.0