Digital Sound

Walt - KZ1F

Let me start off by saying I am not an audio engineer. <- there, after all these decades, to finally get that off my chest. Wheew!

I had asked Tim the other day, after he had mentioned FRS was trying to get vendors past the audio sound card lowest common denominator for digital communications. Well, he didn't actually say it quite like that but you get the idea. I asked him to elaborate on that, as that is a problem I have currently with stuff I am working on.
 
The issue, I believe is converting analog to digital or maybe digital audio to binary?

Sound is a sine wave, perhaps square wave but alternates around 0. The DAX feed is a series of floats from +1 to -1. It's not clear to me why it is important that they be floats if the intent is that the signal varies from +32767 to -32768? I don't know if that is relevant.

Back to the question I asked Tim. In the absence of using a real or faux sound card input and mic output, how would one suggest a product, DM-780 or Fldigi, process digital communications?
It would seem to me at some point in the thread of execution what FRS stuffs into a faux sound card is recovered from DM-780 or Fldigi reading from a faux sound card. If that is actually the case, eliminate the faux sound cards and simply give the app the series of floats or series of integers from 32767 to -32768. (I am going to assume for them to code/decode a vita-49 narrow IF packet is beyond what they appear to be interested in doing). I think it remains outstanding to what extent VITA-49 will become ubiquitous, given the whole, people are still simulating sound cards and rs-232 devices.

Where I am currently is I have packets of 256 floats arriving rather frequently, I believe around 1.5kb/sec. I am still curious what FRS had in mind vis vendors moving beyond faux, or real, soundcards and rs-232. What's next?

Ken - NM9P

Intriguing.  It makes sense to me that as we reduce the number of digital to audio, digital to digital, or digital to faux audio conversions we will ultimately improve performance, latency, and signal to noise ratio.

When they announced the waveform API, I felt sure that someone would quickly try to tackle a PSK31 or RTTY waveform that would decode from radio-to-text (or data) without any additional software other than a light terminal program to handle text transfer and control functions (PTT, Frequency, logging, macros, etc).  It seems to me that PSK31 might be easier to accomplish than RTTY, SSTV, or other Digi modes, but that is only a little more than a guess.

It is way above my current skill set, but other than FDV and D-Star, nobody has taken the bait.  

(I haven't even learned enough C# yet to translate the DJ MIDI Controller program from Processing to C# - something I told myself I wanted to do about a year and a half ago.)

I think the most powerful future relating to the 6000 series may be to entice someone to rewrite their interfaces to include somehow tapping into the Waveform API.  

The next most interesting, but perhaps more universally applicable to other radio brands, would be to tap into the VITA-49 streams as you have suggested.  (Are these two options related, actually? Perhaps the difference between internal and external waveform drivers?

It would be neat to drop the need for all of these different DAX Drivers and simply interface to the digital programs via a "simple" TCP/UDP port assignment.  We would probably need to have both capabilities for a while for backward compatibility, as they are doing in the CAT utility, but it would be a great relief not to constantly fuss with random DAX port "breakage" with Windows updates!

Ken - NM9P

Walt - KZ1F

Well, as I said, while it was intriguing that Flex chose to run with VITA-49 but to look at the VITA collateral, it's intent is for huge constellations. So, from the standpoint of HRD or Dave Freese, is processing VITA-49 packets critical path to processing a stream of floats or integers? I would guess not. My "what's next" wasn't a hypothetical as far as what the industry should do, more, rather than build out Linux virtual ports and  go that route, how did they envision someone dealing with a stream of ints or floats.

Eric-KE5DTO

Walt,

The sample format isn't nearly so important as the interface through which they must be passed.  So whether it is floats from -1.0 to +1.0 (a common format) or signed integers (this is usually used at the driver level), this is relatively unimportant because of the ease of converting between these in very few cycles on today's PCs.

DAX exists today to enable existing applications to talk through their only interface -- namely sound cards.  Our vision for the future is to completely eliminate the sound card from this interface, which should significantly reduce latency and complexity.  Instead, the 3rd party applications would interface directly with the VITA-49 streams coming out of (and into, for TX) the radio.  Imagine -- no more sound card selection, you just select FlexRadio and it just works.  That's where I think things are headed.

Walt - KZ1F

Understood, which is why I said I failed to see the significance of floats vs ints. It was an aside as when I tried to google this they were making reference to some int between 32767 and -32768.  The only two decoder I am aware of are fldigi and dm780. DM-780 sought of defeats the purpose I am intent on providing so that leaves fldigi. I'll have an OOB with Dave on that. However, I was thinking given I have the DAX data was it straightforward to decode that stream into, well, let's start with cw and work our way up from there. If that were the case, I could provide a, if not crude, decoder. 

I do, however, suspect this is an opportunity for FRS to set a standard...or establish the use of an existing standard in the area of ham radio decoders. I suspect you would carry more sway with Dave and Rick than I would. And, of course, providing the code for them would increase the likelihood of incorporation.

Peter K1PGV

To me, the real issue isn't how the IF data is packaged. It's good that it's VITA-49, because that's an existing, very rich, standard. The main issue is that there no standard for rig control (or to acquire IF data) from the radio. So if I write a cool digi-mode program (which is sooo not happening, except in a hypothetical) I can either use the lowest common denominator and support lots of rigs, or I can write some TCP/IP code that's Flex specific and support Flex 6000 series radios. Further, the legacy way is relatively simple (the notorious hideousness of the .Net serial port class notwithstanding), well known, and devs are comfortable with it. Open a sound device and start getting callbacks with buffers of audio data. Open the serial port and start getting callbacks with received serial data. People have been using these APIs in one form or another for at least many years, if not an actual decade in some cases. Sure, FlexLib is sweet... I love using it, it's super convenient, and it's super-simple. But, like I already said, it's entirely Flex specific. Same thing for receiving and parsing network messages directly. Except for that lacks the "super convenient and super easy" parts I mentioned. Ham radio vendors aren't exactly notorious for agreeing to standards. So even if Flex were to more formally propose a standard for network-based rig control, I'm not sure you'd see Icom or Kenwood jump on that bandwagon. Yes... A network connection for rig control and data acquisition is superior in every way. Except one: It doesn't work with enough rigs. I don't know how Flex fixes this. But I wish they could. Peter K1PGV

Walt - KZ1F

And that was kind of my point Peter. If they were told, or noodled it themselves, the size of the research project supporting a single vendor would be for them, yes, I get they won't do it. Further, they can't use flexlib either, well, maybe HRD could, but fldigi is C++. So with a little incentive maybe, like the relevant code. This is why I went for the simple solution of eliminating pushing data into a faux audio card and taking data out of a faux audio card and just giving them data, way easier. Frankly, I suspect neither Rick nor Dave lose any sleep if DAX and CAT get hosed by uSoft. So who has the greater motivation?

Where I think this is important, less so for FRS perhaps than for users and HRD/Fldigi is, assuming in the next 5 years SDR becomes ubiquitous. Other vendors may or may not concur with VSO. If, Flex drove this to vendor support, it would be easier for others to capitalize on the VSO interconnects, I concur on the notoriously hostile to standards, they are still embracing 40 yr old standards. That'll be harder to do going forward. So, for right now, where's the pain point? I am guessing it's on me as I can't do what I want with the equipment I've got. So I am gently trying to get that pain point onto another organization. And, to answer the question forming now in your head, "not so well apparently".  :-)