[hpsdr] Step 1 Question

[Thierbach, Ed]

I think VAC on the client (user interface) side is really the only way to go.  Having a "virtual sound card" on the network would still require some sort of driver on the client end, to take that virtual sound card and turn it into a device that fldigi (or any sound card app) could take advantage of.  Since VAC is well-known and well-used, we might as well just use that.

BTW, I do still think that the interface specs should allow for DSP processing to happen somewhere besides the server end.  Even if that's not implemented in the first pass, I'd hate to write off that possibility so early.  I may very well be in the minority, though, and will certainly go with whatever the whole group decides.

-Ed-

> -----Original Message-----
> From: hpsdr-bounces at lists.openhpsdr.org [mailto:hpsdr-
> bounces at lists.openhpsdr.org] On Behalf Of Graham / KE9H
> Sent: Monday, August 09, 2010 9:43 AM
> To: phil at pharman.org
> Cc: hpsdr at lists.openhpsdr.org
> Subject: Re: [hpsdr] Step 1 Question
> 
> ***** High Performance Software Defined Radio Discussion List *****
> 
> Phil:
> 
> This is what VAC is all about.
> 
> FLdigi expects to hook to a sound card and receive 16 bit audio from
> the jack that that sound card is hooked to.  It puts out 16 bit audio
> to be given to a sound card for transmission to a radio input.
> 
> PowerSDR puts out 16 bit audio for output through a sound card equivalent.
> Also accepts digital audio.
> 
> VAC takes the 16 bits from PowerSDR, and hands it to FLDigi, so that
> FLdigi thinks it is talking to a sound card.  The fun begins if PowerSDR
> and
> FLdigi are running in two different time domains, so VAC also has the
> ability to resample the audio in both directions and cross time domains
> if necessary.
> 
> So either build VAC functionality into the new software, or have an
> interface that looks like a soundcard.  Could be at the GUI, or
> at the signal processing server.
> 
> Or, define a "plug-in" interface so a PSK-31 modem module can
> plug directly into the GUI, or the signal processing server, so that you
> get to recreate/re-write every kind of digital modem software in the
> world, too.
> 
> Many ways to skin this cat, architecturally.  Suggest that openHPSDR
> stick to the radio signal processing until things are under control there.
> 
> --- Graham / KE9H
> 
> ==
> 
> Phil Harman wrote:
> > ***** High Performance Software Defined Radio Discussion List *****
> >
> > All,
> >
> > Just received this interesting and thought provoking question from the
> > dttsp-linux reflector regarding our digital data plans.
> >
> > Comments and suggestions welcome.
> >
> > 73's Phil...VK6APH
> >
> >
> > Phil
> >
> > Interesting - as a data mode ham, I have a couple of questions:
> >
> > "All DSP on the server" - now how does this split work for say PSK-31? On
> > my current
> > setup I take raw I/Q audio via jack from the softrock, dttsp does the hard
> > work of
> > selecting an chunk of spectrum, and this reappears (again in jack) as an
> > audio
> > signal. FLdigi is connected to this, and does not know it wasn't connected
> > to the
> > headphone socket of a 'real' radio.
> >
> > Would your design export the intermediate audio (realtime across the
> > network), or
> > would you split fldigi to run its modem(s) on the server, and export
> > decoded text
> > (plus non-realtime waterfall data) to the client?
> >
> > One other detail - is this work GPL v3 or GPL v2?
> >
> > 73
> >
> > --David G8SQH
> >
> >
> > ___
> 
> _______________________________________________
> 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/

 1281362581.0