What does VAC and VSP drivers do?

  • 1
  • Question
  • Updated 3 years ago
  • Answered
Feel free to correct me if I state something factually inaccurate.

Most, if not all, ham radio digital programs, psk, rtty, cw decode programs expect input from an analog audio in, be it line in or mic input.On my ts-530sp I wired another mic cable to be audio in from the multitude of digital equipment I had (largely Heathkit). Or they use(d) rs-232, another relic from the 80's.  For some obscure reason I always thought the 6000 series had an audio out and audio in on the rear panel for those that could not use DAX. I was clearly mistaken. I know, heresy huh, "could not use DAX" While DAX is internal to the black box, providing a fake sound card interface is not.

I am going to assume I am not alone in having a non Microsoft control surface to the 6000 that is devoid of digital mode use. Strictly speaking, it is not the control surface that is devoid of digital mode, it is the absence of the VSP drivers that makes it so.

There are likely going to be some sub questions in this.

As XPSLib is a functional replacement for FlexLib, I can create DAX streams. While I can create them it is not clear what I can do with them as I suspect their consumption is in the SSDR GUI, which is not available source. And, as I suspect, from there they feed through the VSPMgr in order to construct something that will look like an analog audio in (DAX RX 1(..8) which DM780 or fldigi can connect to.

The flip side of all this is handling the audio in from DM780 or Fldigi.
I believe what is pivotal in this dilemma is not only the role Virtual Serial Port Kit (assuming that what some refer to as VSPMgr) plays in this and, internally how does it do it.

Thanks,

Walt  - kz1f
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes

Posted 3 years ago

  • 1
Photo of Mark Erbaugh

Mark Erbaugh

  • 384 Posts
  • 34 Reply Likes
I don't believe SSDR is involved in converting the DAX streams to and from audio devices as you run DAX and have audio streams on a separate computer from the one running SSDR. In the future (4th quartet - hey isn't that here?), we will be able to control the radios with Maestro and run our digimode software on a separate computer.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
I am not adding yet another computer to run the 6500.
The dax tx and rx channels are not instantiated in flexlib. My belief is the specific digital audio channels are scheduled/created via flexlib (xpslib) but that still leaves routing and dac processing to something else, I suspect that routing is done in the gui with the assistance of the VSP drivers.
(Edited)
Photo of Doug Hall

Doug Hall

  • 187 Posts
  • 54 Reply Likes
"For some obscure reason I always thought the 6000 series had an audio out and audio in on the rear panel for those that could not use DAX. I was clearly mistaken. "

I don't know the answer to your question about DAX streams, but according to the Flex-6000 Hardware Reference the accessory connector on the rear panel has line in/line out signals. Have you found this not to be the case?

Text from hardware reference manual pasted below:

7.4.1 Pin 1: Line InThis audio line input can be used to feed consumer level (-10dBV) audio into the transmitter. Refer to the SmartSDR documentation for information describing how to enable this input, and what configurations are available.
7.4.2 Pin 2: Line1 Out
This audio line output is a buffered output of the POWERED SPEAKERS left channel.
7.4.3 Pin 3: Line2 Out
This audio line output is a buffered output of the POWERED SPEAKERS right channel.
7.4.4 Pin 4: KEY/FSK/INT In
This input is a keying input for either CW or FSK. Refer to the SmartSDR documentation for information describing how to enable this input, and what configurations are available. Pin 4 is keyed to GROUND.
7.4.5 Pin 5, Mono Audio Line Out (FLEX-6300 only)
On the FLEX-6300, pin 5 is a mono (left / right combined) audio line output for connecting external device such as modems or TNCs.

73,
Doug K4DSP
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9148 Posts
  • 3466 Reply Likes
@Bob - From what I understand, pin 5 on the 6300 is not implemented, so it does nothing.
Photo of Bob Wright, N7ZO

Bob Wright, N7ZO

  • 268 Posts
  • 66 Reply Likes
The reason I am asking is I still have an SCS PACTOR modem attached to my old radio that I would like to move to a Flex radio. I currently have a 6700 but would buy a 6300 if it had the fixed output.

Is there hardware in the 6300 that would someday allow the implementation of the fixed output or was the the hardware not implemented too?
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9148 Posts
  • 3466 Reply Likes
I am fairly certain that it is a software change.
Photo of Alex - DH2ID

Alex - DH2ID, Elmer

  • 891 Posts
  • 166 Reply Likes
Bob, I have been using SCS TNC's for PACTOR for EMCOMM work
here for some time now, before that I had them on board my ship.

I would never dream of putting a PACTOR modem on a SDR TRX.

Why? Because they work just as well with the "old" TRX like the
IC-756PRO we use at our club EMCOMM station at at home here,
or my FT-897D and FT-857D, which are easily portable, don't need
a PC to set up an automatic station and have very fast switching
RX/TX relays. I have had my IC-756PRO running for weeks as an
automatic PACTOR mailbox and never had a problem,
even in thunderstorms.

My advice to anybody wanting to do PACTOR is: keep your good old
TRX, don't burn up your expensive SDR relays.

I've tried PACTOR on all my SDR's (3000,5000,6500) and it kinda works,
but with problems with TX/RX latency and having to leave a PC running
unattended. For short time PACTOR work SDR's are fine, although
a bit overdimensioned... ;-)

Just my 10p worth...

73, Alex DH2ID
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes
The slightly harder question I was asking was of a programming variety. There is no doc on how the AudioStream class is used in SSDR GUI

Did you happen notice that the audio stream created with CreateAudioStream is described here.  I don't know if that gets you any closer to what you were looking for.

Peter
K1PGV
Photo of Doug Hall

Doug Hall

  • 187 Posts
  • 54 Reply Likes
Walt,

I'm more of an embedded systems guy, so you've done more high level development with the Flex than I have. But I don't see how DAX and VSP Manager have anything to do with each other. My understanding is this, and I'm probably not telling you anything you don't already know: when you enable a DAX channel in SSDR (or presumably in your own software) the radio makes audio samples available via a unicast (UDP) stream. On the client side you open a UDP connection to the radio and audio starts streaming. The problem is (and again, this is just my understanding) none of the existing digital mode software knows how to talk to the radio this way - these programs only know how to talk to Windows sound cards. So DAX on the PC side emulates a sound card (or several sound cards) and also handles the UDP stream from the radio. I don't think VSP Manager enters into it, but maybe you're talking about a different piece of software. I think I used VSP Manager back in the PowerSDR days and it came from K5FR. It was just for CAT and keying related stuff. Are you referring to something else?

It seems to me that in order to use DAX channels from the 6000 in any non-Windows OS you'd need a virtual sound card for that particular OS that understands streaming. PulseAudio can do this, although it seems to have fallen out of favor with developers these days and now everyone is raving about something called Jack instead. (I don't know Jack, literally :-) W7AY has also done this with his NetAudio framework under OS X. In any event, I think you need to hack together a "DAX-aware" sound card driver for whatever OS you are running on if you want digital modes with the Flex-6000. If you find out otherwise I'd be interested to know the details.

This is only based on my (admittedly) limited understanding based on what I have read so far.

73,
Doug K4DSP
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
"when you enable a DAX channel in SSDR (or presumably in your own software) the radio makes audio samples available via a unicast (UDP) stream. On the client side you open a UDP connection to the radio and audio starts streaming. "

Yep and nope. here's what happened. The Linux box that was my dev system XPS720 died a month or so ago. That system had my source and executables on it. Fortunately, about 2 weeks before it died it occurred to me I had no backup of it, so I did back up home. I got a replacement POS Insiron 5347 or some such that I kept Win10 on...another POS and installed Linux next to it. The audio did not work on it, not on Linux, not on Windows. By the time I could convince Dell the system didn't have audio they scheduled a guy to come out and replace the motherboard. He did but it was a refurb where the cpu was sticky taped down (no sh!t) as the pins on the socket were bent and nobody thought to unbend them.

Well, if people on here think I speak my mind...HA...I went off on them. They sent me a whole new machine that arrived mid week. I do recall Pulse Audio is(was) still in use as of the 2014 LTS. But right now I am on the Windows side. As painful as designing a non-Windows control plane was, that is the easy part. There is no digital and no logging. CQR runs on Linux but doesn't do Flex. What I want is something that is loosely coupled but, nonetheless, coupled to the radio. Then I have to get the logs to QRZ, LOTW and Clublog.  

I know how to do virtual ports on Linux, but, as you kind of imply, that may be less than necessary..well...doesn't one use a port to toggle PTT? And the use case for DAX is from the client side you configure it to use DAX RX channel n and DAXTX channel n, I believe from the perspective of HRD or Fldigi it simply connects to what it perceives as an audio device that shows up when you list all your audio devices. This actually happened when the tech in India was debugging the no audio problem. It looked like the headphones were plugged into the dax channel. There was also an AMD device that was the HDMI on the new video card.

What shows up in the list is a named device. To the extent I have visibility into anything, I know the API Flexlib uses and I know what it does. I know there is a 32 bit dax_32.exe that graphically lists all the potential dax channels and if they are in use and if the transmit is set and allows one to set the (audio) gain on them. If you open task manager  32 bit Virtual Serial Port Kit service and, if you look under Flex Systems folder there is a FlexVSPInstaller, audiodax.sys and txdax.sys and iqdax.sys. Since it doesn't appear that flexlib does anything with any of those I conclude that the GUI does.

Oh cool! I didn't think to look here. I was looking for the audio mixer and found connected devices, the VSP stuff appears to be for CAT. So one variable removed. Found the sound app, it shows all the dax reserved, tx and rx devices, 1-8.

OK, actually you've been very helpful Doug! the VSP and VAC have nothing to do with DAX. I'll see if I can't change the title. So the question becomes (or still is) how does DAX go from an available UDP source to an audio device input or output, and what is the deal with the reserved devices?


Rats, I thought I had figured out how to change a title....maybe it is time limited.


I mentioned CQRLog. not doing Flex. AND it's written in something I've never seen nor ever heard of. So adding that functionality is a non-starter. I've also talk to the fine owners of HRD and N1MM, I doubt they could be less interested in a portable version of their program. The guy that bought HRD rights, name of Rick, I believe, is ex-uSoft. Now I am kind of wedged as I can't say anything bad about uSoft or it's culture. I don't know what the deal is with Steve and N1MM is, beyond they had no interest.
(Edited)
Photo of Jon - KF2E

Jon - KF2E

  • 638 Posts
  • 189 Reply Likes
Walt,

Maybe I'm missing something here but VAC and VSP provide two separate functions.

First VSP...

VSP(or SmartCat) is used to create virtual serial ports. Yes, just like those we used on computers of old. By creating a virtual serial port pair in the operating system you allow SSDR to be connected to software like Fldigi. The serial connection allows for CAT commands and depending on the application PTT. So your digital program thinks it is connecting to a real serial port and SmartSDR is waiting at the other end. PTT is normally accomplished by asserting DTR or CTS.

And VAC...

Back when we had PowerSDR audio streamed to the radio across the firewire connection. So that audio could get to an external application a virtual audio cable was used. It created a virtual audio recording and playback channel that the OS saw(Windows). This allowed PowerSDR to be connected to one end and your application to connect to the other end...no wires. Today, VAC has largely been replaced by DAX. It provides 2, 4 or 8 audio connections that allow audio to be passed to/from external applications. These show up as audio record/playback devices in Windows.

None of this helps you much as a Linux guy. DAX is Windows as is SMartCat. If you want to program something you would need to be able to open an audio stream from SSDR and make it appear as an audio recording/playback device in Linux. Your external application(fldigi?) would then need to see it as such.

Sorry if this doesn't help/make sense. It's my best shot at giving some clarity.

Jon...kf2e
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
Thanks Jon. I wish I could have changed the title. As you said, as did Doug. I got two things confused. I realized or so I thought that VSP is the 6000 equivalent to VAC as I used that with the 1500, back when I was using the 1500. So the thrust of my question is this:

As I was telling Doug, I don't have the source in front of me so I can only speak now from recollection. Flexlib (and XPSLib) request a dax 'channel' from the radio. Flexlib does nothing with devices so the stream returned by the radio to flexlib is ultimately returned to the GUI. I suspect this transpires as a result of a slice specifying a given dax channel. I believe the GUI side of SSDR passes that information to some other piece of (proprietary) code that actually creates the faux audio device that the third party app connects to.

There is nothing magical about Windows. (There...I said it). Nothing one can do in Windows can't be done in some other OS, just not the same code. So my question really is, at a depth one can reasonably understand the high level design, what happens outside of SSDR that allows a third party app to think it's talking to a sound card. Above I mentioned some of the driver names used, one for receive another for transmit.

I would like a DAX (work alike) that works on other than Windows.
So I think what this comes down to is how much of what FRS has not made public, either via source or explanation, are they willing to, upon further reflection on the subject. There are a couple of 'frontiers' left before what FRS did with SmartSDR for Windows can be anything other than for Windows. I am not alleging they have to do portable versions, clearly they don't.

I haven't been following what the software for MAC has or doesn't have. And, I realize for many, perhaps most, tethering the 6000 to a windows machine is a non-issue. For those people I merely ask they understand and appreciate for some, more than just me, it IS an issue.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes

DAX and VSP each provide a driver and a user-mode application to manage the driver.

The VSP driver is a software-only driver that creates a (virtual) serial port device on Windows.  Applications (such as digital mode apps) access and use that serial port device in the normal ways.  Windows doesn't know this isn't a real, physical, serial port and (because a driver is provided for it) does nothing to handle it (other than "helping" to manage the legacy COM port number).  The VSP driver supports the standard upper edge interface that any serial port device supports.

The CAT application serves as the intermediary, receiving data that applications write to the virtual serial port and translating those commands to FlexLib commands to the radio, and getting responses from the radio via FlexLib and translating them to serial port responses that applications expect.

The DAX driver works the in the same way, except for audio.  DAX creates a standard (virtual)  audio device, with an upper edge interface that supports the standard Audio Multimedia Device API .  Windows treats this exactly like the upper edge of a sound card, and doesn't know it's not a real, physical, sound card.  The DAX application serves as the intermediary here, shuttling data between data from the radio received via FlexLib and the DAX driver. I'm not super-clear on the details of the format of the data that's exchanged, because I know almost nothing about the Windows multimedia stacks (it's not my area of practice).

I hope that helps.  Is that the level of detail you needed?

Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
Hi Peter. First off, thank you. What do you mean by 'upper edge'? I think the last class I had at Microsoft university was on device driver development. That was 88/89 time frame. I came back,wrote a few drivers for OS/2 and aside from consulting on one or two, that was my forray with device drivers. But, to more directly answer your question, no. What I'd really like is this to be an opportunity for FRS to consider exposing more of what they didn't make public, either in souce or by DDS.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes
Sorry for lapsing into jargon there, Walt.  By "upper edge" I mean the interface that the driver exposes to consumers (applications and/or other drivers in the system), consisting of a set of Read, Write, or IOCTL functions. For the (virtual) serial port, for example, see this list of IOCTL functions.  Tim, K3TIM, provided a link that's a nice architectural reference.

There is likewise a standard set of functions expected that are expected to be provided by a "standard" Audio device, that are consumed by the standard MSFT audio driver, which exports these functions to user mode.

What I'd really like is this to be an opportunity for FRS to consider exposing more of what they didn't make public, either in souce or by DDS.

Well, as I'm sure you know, the CAT software already IS open source. There's nothing that's even the least bit interesting or proprietary about the Virtual Serial Port Driver (and I suspect that Flex simply licenses an existing one unchanged).

I'd be surprised if there's anything sure interesting in the DAX application or the DAX driver.  To port this to another OS, consider how you make virtual devices appear on that OS, and write a driver that simulates that... getting data from the radio via FlexLib.

While I'm not an expert on the internals of, or writing drivers for, any OS other than Windows... I bet whatever it is that needs done on the audio side (for example) will be much more easily done on Linux (for example) than it is on Windows.

Peter
K1PGV
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
Thanks Peter. Part of the rationale for that stmt you highlighted is there are dax tcp commands that flow as a result of calls into the AudioStream class, completely undocumented, neither internally or externally. Frankly, neither are any of the others, not that come to mind but they were only one level of indirection away so a little playing worked wonders. There are visual objects in the gui that bind to variables in flexlib. In some cases these variables are set as soon as the response flows as well as when the status message is parsed and the new values are extracted. That stuff is just kind of pita but it is decipherable. My feeling with DAX there are 2 levels of indirection so it is not so obvious.

I toyed with rewriting CAT, didn't as I thought most vendors were writing native flexlib code rather than emulating a really old kenwood spec to drive ascii text to the radio so that was a bridge I didn't feel I needed to cross.

Frankly, programming opportunities was not on the list of reasons I bought the radio. Yet here I am. Thanks for the link Tim.