[hpsdr] Starter question

[James Courtier-Dutton]

Philip Covington wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> On 11/15/06, Christopher T. Day <CTDay at lbl.gov> wrote:
>   
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> Bob,
>>
>> The way the protocol is currently designed, all the audio data and
>> SDR-1000-type control data are interleaved into one byte stream into Ozy
>> and one byte stream out. So, no, I believe you will not be able to run
>> these functions in separate processes easily. Part of the idea of making
>> the Janus/Ozy combo into a real audio card would be to separate the
>> control functions into separate pipes so that multiple processes could
>> work with the hardware as you would like. However, nothing much has come
>> of that effort so far. [I've been one of those pushing that idea, but
>> haven't managed to actually produce anything so far.] Note that this
>> would involve a fairly deep redesign of the firmware in the FX2 and the
>> CPLD/FPGA configurations.
>>
>>
>>         Chris - AE6VK
>>     
> 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. It 
would not add any latency overhead by separating these. The best 
improvement to latency would be to use USB 2.0 high speed instead of 
full speed. I don't know which speed the OXY will be using. Using USB 
2.0 high speed could also help with the import of more data from the 
Mercury board, for purposes of passing high speed sampling direct to the 
PC, for maybe the purposes of a high speed storage oscilloscope or 
better panoramic display.

I was going to try to write a Linux driver for the OZY usb, but probably 
will not do it now because the current packing approach involves too 
much work and adds unnecessary CPU overhead in processing the samples 
due to extra memcpy() required when demuxing the stream. It is better to 
get the USB hardware to do the demuxing, and not the CPU.

James






 1163600001.0