[hpsdr] Proposal for a new Software project.

[Frank Brickle]

<http://opensoundcontrol.org/introduction-osc>

It's also worth noting that many of the issues that have come up in this
discussion have been addressed at some length in connection with XMPP.

Just to make note of it, I am continuing work in deadly earnest on the
system originally discussed in the FSM paper, although there have been a few
detours along the way.

Contrary to some of the discussion here, I've been persuaded that it's not
the API that matters, it's the namespace and service discovery protocol, and
that there are perfectly usable models for these in both OSC and XMPP.

Similarly, many if not most of the issues involved in IF and baseband data
transport have been worked over at length in connection with both CoreAudio
(Mac OS X) and PulseAudio. These systems are very similar under the hood.
It's hard to see how they could be improved on.

73
Frank
AB2KT

On Tue, Dec 1, 2009 at 7:05 AM, Jeremy McDermond <mcdermj at xenotropic.com>wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> On Dec 1, 2009, at 5:26 AM, John Melton wrote:
>
>> The client server interface is fairly simple.  It uses a TCP connection
>> for commands but uses UDP for the I/Q samples and any returned audio.
>>
>
> Maybe this is way too complex to implement for what we want, but I've been
> thinking about the problem of a "HPSDR Server" a bit, and it seems to me
> what we're implementing is a essentially a streaming media server with I/Q
> data.  It makes a certain amount of sense to me to use existing protocols on
> the wire, so it might make some sense to consider RTSP/RTP for transporting
> control and data in this case.  We can come up with some sort of URL format
> in the RTSP port to specify receiver and frequency, and we can use RTSP to
> set up RTP streams on UDP ports for the clients to pick up.  A frame format
> can be defined or stolen in RTP for the I/Q data we need as well.  We can
> probably use some of the work of others in the forms of RTSP/RTP libraries.
>  The advantages of this are that RTP is designed to transport time-sensitive
> media like this that requires a low amount of jitter.  We're not too
> different than streaming video or audio in that regard.  Additionally, RTSP
> and RTP are well understood, and will flow past many firewalls without any
> problem.
>
> Again, a fairly ambitious idea, and maybe not a "1.0 feature" but something
> to think about at least.
>
>
>
>  Regards,
>>
>> John g0orx/n6lyt
>>
>>
>>
>>
>>
>> _______________________________________________
>> HPSDR Discussion List
>> To post msg: hpsdr at openhpsdr.org
>> Subscription help:
>> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>> HPSDR web page: http://openhpsdr.org
>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>>
>>
> --
> Jeremy McDermond (NH6Z)
> Xenotropic Systems
> mcdermj at xenotropic.com
>
>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help:
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>



-- 
The dose makes the poison. -- Paracelsus

Please note new phone numbers:
mobile: (908) 442-8863
work: (908) 428-4916
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20091201/8c2813d6/attachment-0004.htm>