What does VAC and VSP drivers do?

Walt - KZ1F

Mark Erbaugh

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.

Doug Hall

"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

Walt - KZ1F

Doug, I certainly could be mistaken, my understanding was that was strictly the 6300. Pins 2 and 3are for powered speakers. Given their differentiation from pin 5, I am guessing pins 2 and 3 don't represent 'audio cables'. The 'obscure reason' referenced my thinking there were audio in/out sound card compatible plugs.

Walt - KZ1F

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.

Doug Hall

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

Walt - KZ1F

"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.

Jon_KF2E

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

Walt - KZ1F

Peter K1PGV

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?

Walt - KZ1F

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.

k3Tim

https://msdn.microsoft.com/en-us/library/windows/hardware/hh706280(v=vs.85).aspx

Peter K1PGV

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

Walt - KZ1F

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.

Tim - W4TME

You are mistaken.  All 6000s have line in/out audio on the ACC connector.  See the reference in the FLEX-6000 Hardware Reference Manual.

Walt - KZ1F

Tim, Doug copy/pasted them right above my post that you responded to. If you are referring to pins 2 and 3, aren't they left and right powered speaker? Or are you saying pin 5 is active on all models? Would you elaborate on how connecting both pins 2 and 3 and connecting them to the non ground 3mm plug going into line in on a sound card is different than using the output of pin 5, if one had a 6300. I assumed where it said left / right channels for a powered speaker they were different than momovline out.

Tim - W4TME

So here is the story on the elusive "pin 5".  In the FLEX-6700 and FLEX-6500 it is a ground pin.  For the FLEX-6300, there was a commercial request to provide a constant gain line level  output for devices like modems and TNCs.  The powered speaker outputs can be used, but the gain (volume) on the power speaker outputs is variable, which can mess with decodes.  So we co-opted pin 5 on the 6300 for this use.  However, due to some changing priorities, we did not have to make the change and the line level output was never actually implemented in the 6300.  But getting the doc changed to reflect this fell through the cracks (which has now been corrected). 

Walt - KZ1F

I have a 6500. If I join pins 2 and 3 and connect that to the non-ground of a 3mm mic plug will that work as the signal input to a non-DAX / non-Windows digital decode app? Stated differently, will the combination of pin 2 and 3 be equivalent to the source for a line in on a sound card? Similarly, pin 1 would connect to the line out on the sound card?     Tim, I am attempting to run digital in a non Windows non-DAX environment. So maybe the easiest way to ask the question is how do I accomplish that.

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. Nor is there any doc on the flow of control and architecture of what happens that creates the audio devices 1-n for rx and tx. So rather than ask, in a series fashion a whole sequence of question I tried to make the question sufficiently defined that someone, Eric, Ed, perhaps Steve could respond with a 'here are the missing pieces'. Only in the absence of a software solution would I be left with a hardware solution.

Tim - W4TME

"I have a 6500. If I join pins 2 and 3 and connect that to the non-ground of a 3mm mic plug will that work as the signal input to a non-DAX / non-Windows digital decode app?"

Just use the left channel (that is convention)

"Similarly, pin 1 would connect to the line out on the sound card?"

yes, but you need to isolate the connections electrically to prevent audio ground loops.  This is covered in about a bazillion references on the web.

On your last question, I would ask that as a new Community post rather than tagging in onto this one.  It would be beneficial to the anyone doing API programming who is interested in streaming audio from the radio.

Bob N7ZO

Hi Tim,

I understand that the fixed-level output was never implemented on the 6300.  But is pin 5 on the 6300 now a ground or a variable level output?

73, Bob, N7ZO

Walt - KZ1F

Thank you.
Point taken.
and I agree...a new thread.

Thanks Tim. Ideally I want a non-Windows DAX solution.

Tim - W4TME

@Bob - From what I understand, pin 5 on the 6300 is not implemented, so it does nothing.

Bob N7ZO

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?

Tim - W4TME

I am fairly certain that it is a software change.

DH2ID

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

Peter K1PGV