[hpsdr] Starter question

[Bob McGwier]

I agree with this!   We want synchronous and asynchronous data streams 
divided to the extent possible!


Bob
N4HY


James Courtier-Dutton wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
>
>
>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>
>   


-- 
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(sig required by employer)



 1164736458.0