Wrong Bit Depth or Rate in DAX

  • 3
  • Question
  • Updated 1 year ago
For months third-party apps such as WSJT-X and FLDIGI functioned just fine. But recently, I've had trouble with WSJT-X not decoding any data. To troubleshoot, I used the Windows audio utilities to listen to the stream DAX was sending to the app and it was messed up ("crackly") in a way typical of a wrong audio bit depth or rate. I killed and restarted DAX and the problem resolved in the case of one instance of WSJT-X. But another instance (I use a WSJT-X command-line argument that prevents multiple instances from having conflicts over a common log file, etc.) did not perk up. Many minutes later I noticed the problem (having wrongly assumed that there simply was no data) and restarted DAX a second time, at which point the second WSJT-X instance also began functioning correctly.

Lots of questions follow. But those which seem to me most important are:
1. Why did this problem show up only recently (apparently owing to installation of SSDR/DAX 1.10.16)?
2. Am I rightly diagnosing the problem as inconsistent bit depth/rate?
3. Is there a better way of ensuring compatible bit depth and rate than killing and restarting DAX while hoping for an improved result (bit depth/rate roulette)?
Photo of W B McCarty

W B McCarty

  • 8 Posts
  • 3 Reply Likes

Posted 1 year ago

  • 3
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3471 Reply Likes
I suspect that the issue you are experiencing is not a sample rate / bit depth issue.  This is easily confirmed by interrogating the DAX sound device's advanced properties.  It should be 2ch, 16-bit, 48k for regular DAX audio devices (not DAXIQ).

Why did it just start showing up?  The question you need to ask is what changed in your PC environment lately?  Has your Windows machine recently been updated?  As a side note, the DAX drivers have not been updated in a long while, so I do not suspect that is a significant change factor.

What I do suspect is that you are experiencing some sort of buffer corruption that is mitigated when you stop and restart DAX.  I also think that long duration DPCs may be a factor (https://helpdesk.flexradio.com/hc/en-us/articles/202118398-What-are-DPCs-and-why-do-they-matter-)

You may want to run LatencyMon while using the radio as described in the article I referenced.  Monitor the DPCs until you observed the corrupted audio behavior and then look at the results.  If it indicates that your system may not be suitable for processing real-time audio, then this may be the culprit.
(Edited)
Photo of Bill W2PKY

Bill W2PKY

  • 453 Posts
  • 79 Reply Likes
I run the radio on digital 24X7 and notice occasionally the transmit buffer corruption by watching the shape of the transmitted waveform in the panadapter display. Additionally, usually have the "MON" on and listening to the transmitted audio.
Photo of W B McCarty

W B McCarty

  • 8 Posts
  • 3 Reply Likes
WX7Y: I'm not doing any transmitting. But your experience seems, at root, a lot like mine. Same fix, anyway. 

W2PKY: As I wrote to WX7Y, I'm not transmitting. But I do run multiple instances of WSJT-X (each on a different HF band) often for days at a time. I've done this for several months without apparent problem. But the last two weeks or so I've had a problem of the sort several have described. 
Photo of W B McCarty

W B McCarty

  • 8 Posts
  • 3 Reply Likes
It's important to distinguish two categories of problem that seem to me to be confounded in this discussion. One is the sort of problem intended to be analyzed by LatencyMon. This sort of problem is caused by the dynamic inability of the system, for whatever reason(s), to process audio IO requests timely. This sort of problem does not affect system state. That is, the only "corruption" involved is the immediate corruption of the audio stream, which ceases to be corrupted when the system becomes able to process audio IO requests timely. That does NOT appear to be the sort of problem I'm experiencing. The problem I observe is one that involves persistent corruption of state. Even in the case of a relatively quiescent system the audio stream remains corrupted because the program instructions or data, or both, have become permanently corrupted. This second sort of problem is typically due to a software defect ("bug").

I find it significant that the only audio devices that exhibit corrupted audio are the DAX devices. This strongly suggests to me that the problem may be due to a software defect in the DAX driver.

Unfortunately, LatencyMon is of no help to me because it causes my system to hang. I have contacted the maker asking for relevant information/assistance. 

None of us is in control of our system configuration because Microsoft pushes fixes, some of them necessary security fixes, on an ongoing basis. We cannot responsibly omit installation of such fixes. The only other software version change I'm aware of is my installation of SSDR 1.10.16. I find that fact doubly interesting. 

At one time my system was used for music production, a task perhaps even more demanding as to real-time handling of audio than SSDR. However, it's not reasonable for me to spend time analyzing the system because it is immediately due for replacement, the new system having already shipped. I have also had pending an order for a Maestro unit since mid December. 

As to the weight that might be given to my opinions, I confess no special knowledge of Microsoft operating systems. However, I am a PhD professor of mathematics and computer science and have taught operating systems courses since at least the early 90s, operating systems being one of my areas of special interest. I cannot and do not lay claim to infallibility. But when it comes to general knowledge of operating systems and software engineering, another of my areas of special interest, I can assure you that I know whereof I speak. This problem does not appear to me to be the result of a temporary dynamic inability to timely process audio IO requests. It appears to me much more likely to be the result of one or more software defects. These defects could be in SSDR, the Windows operating system, or third-party software other than SSDR. The problem could even be due to a subtle interaction between defects originating in distinct sources. The fact that the audio stream can be returned to proper operation by restarting DAX tends strongly to confirm this hypothesis as to the cause of the problem as distinct from a hypothesis attributing cause to some sort of dynamic insufficiency of system processing power.

I apologize for the many long words but I simply don't have time to write fewer, shorter words. I trust that it's at least possible to work out my meaning.

Cheers,

--WB6LA
Photo of Bill W2PKY

Bill W2PKY

  • 453 Posts
  • 79 Reply Likes
Hello WB-

No apology is necessary, many of us myself included have experienced corruption of the DAX receive channels at one time or another. Having worked on big iron for more years than I like to admit I find trouble shooting the Windows environment frustrating to say the least. Take my recent experience with Win7 Pro. The environment was stable for many months until I did the April roll up. SSDR started crashing within an hour. Rolling back that update did not cure the crashing problem until I did an "OKAY Power on Reset" and restored my profiles???? I am thinking maybe an "OKAY Power on Reset" is a good idea when ever anything changes on the PC.

I tried the free Win10 Pro upgrade on my ASUS Z97-A MB and had the same issues as you describe. However, just when I thought DAX must have a coding defect I ran SSDR, DAX and JTDX without an issue on my 2 Surface Pro machines that have all Win10 Updates applied. So trying to make a logical deduction in this arena is fruitless. 

I am now thinking Windows O/S is not fully tested on enough hardware platforms. Some work some don't??


Perhaps you can let us know your HW and O/S version, update status etc. 
Have a look at the Installed O/S updates and see if there was an update corresponding to the start of your DAX corruption problem.

Hopefully your new machine performs better. Keep in touch.
(Edited)
Photo of NM1W

NM1W

  • 133 Posts
  • 24 Reply Likes
WB - Great writeup; I too experience the dax corruption; Quite often for me its on receive, and visible in the wsjtx waterfall. When its dax xmit corruption I usually find out the hard way when the other station keeps repeating and they are a solid signal.. (I need to remember to turn on MON like W2PKY so I can hear it.)

If the dax corruption was a packet loss, or corrupt packet I'd expect dax would recover; However since dax doesnt recover it would seem to be something else that once broken requires a dax restart...

For me I'm running win10 the anniv update, on a fast system; latency mon seems to be satisfied with my system, but I've even gone so far as a full wipe and reinstall of win10.. No change in the dax corruption behaviour...I even have swapped out win10 machines and done a fresh install on the new system. Again no change in dax random corruption...

My current config is: asus x99-A II; I7-6850, 32GB ddr4; samsung m.2 ssd
win10 1607 build 14393.1066
Photo of Harry Williams

Harry Williams

  • 98 Posts
  • 8 Reply Likes
I too have been having trouble with wsjt-x with rx decodes. Things will run fine for long periods of time and then all of a sudden I notice I am not getting many or any decodes when there are lots of signals present. I also noticed that the signals on the wsjt water fall look kind of fuzzy...like the gain is way to high yet the background blue looks about the same intensity. Also the gain display in wsjt looks ok, I then stop and restart DAX and things go back to normal. I am using the 1.10.16 ssdr release, win 10 with latest updates (not creator) on a fast machine with lots of memory. I am new to wsjt so am not sure now long this issue has been present. I have not noticed any transmit problems. As others have mentioned, once this condx occurs only a restart of DAX will straighten things out.

Harry
W0LS
Photo of W B McCarty

W B McCarty

  • 8 Posts
  • 3 Reply Likes
Harry wrote: " I am using the 1.10.16 ssdr release, win 10 with latest updates (not creator) on a fast machine with lots of memory. "

Ditto.

But. . . inventorying software versions is a losing game unless dozens of users participate. One reason this is so is that the versions are moving targets. That is, the versions won't be the same next week after Microsoft releases new software. Or my anti-virus vendor does so. Or my audio device vendor does so. Etc. Etc. 

And, fundamentally it's the programmer's responsibility (and hence, the vendor's responsibility) to write software in a way that it is not unrealistically sensitive to variation in the software configuration. Users can't realistically be expected to navigate a software-version maze. If a program has sensitivity to aspects of the hardware or software configuration that might not be met by the typical off-the-shelf PC, it's the vendor's responsibility to enumerate these before the fact so that the user has some chance of being able to comply. Otherwise, it's fundamentally a game of "gotcha!"

In the case of SmartSDR I wonder if my Apple iPad demonstrates the same problem. And likewise, I wonder if my Maestro does so. Of course I can run the program on my iPad and find out. My Maestro, which was ordered in December, has still not arrived. So I don't know whether it demonstrates the problem or not. I have a very fast, loaded with RAM PC I just purchased that I'm also curious about. So far, it hasn't demonstrated the problem. Perhaps it won't. But my other PC, though several years old, was a powerhouse when it was purchased. It's not as though it's second rate even now.

Cheers,
Photo of Alex - DH2ID

Alex - DH2ID, Elmer

  • 914 Posts
  • 169 Reply Likes
I had some DAX problems a while ago and resolved these by deleting DAX and CAT from the autostart
folder and writing a batch file, which starts all 7 programs I need to run my radio: DAX, CAT, MiniDeluxe, SSDR, WSJT-X, HRDLog, FRStack. I start this batch file only when my notebook has looged into my network, my Flex6k5 shows a green LED and everything runs fine. No problems now with DAX - ever. 
Vy 73, Alex - DH2ID
Photo of Bill W2PKY

Bill W2PKY

  • 453 Posts
  • 79 Reply Likes
When I start DAX after SSDR is settled down I get dropped packets. If starting DAX first then no dropped packets.
Photo of Alex - DH2ID

Alex - DH2ID, Elmer

  • 914 Posts
  • 169 Reply Likes
Yes, that is normal, Bill, always start DAX first.
Photo of Rory - N6OIL

Rory - N6OIL

  • 262 Posts
  • 47 Reply Likes
Alex in your batch file do you have startup delays for some of the programs that have interdepencies? Could you share your file?
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes
It sounds to me like WB6LA iand company are onto something.

One of the few things I know well is the internals of the Windows operating system, at both the architectural and implementation levels. WB6LA's analysis doesn't point to a DPC issue to me... and is more likely to be structural in some way. It could be an OS or driver bug... but it feels more like an app buffering problem. The problem points to DAX because stopping and starting it seems to resolve whatever the error is. But this doesn't HAVE to be a DAX bug. It COULD be a bug in the way some driver buffers data before it's passed to the app.

But, as I think we've all said, it's hard to diagnose, and even harder to fix, without a predictable reproducer.

Peter
K1PGV
Photo of John  - W8AGS

John - W8AGS

  • 43 Posts
  • 13 Reply Likes
Alex
I also experienced some problems with DAX and sometimes with CAT from time to time. So like you, I took both DAX and CAT off from auto-start. I now let the PC boot up completely then manually start DAX and CAT. Then I start SSDR running. Since then I've had no bad behavior of DAX or CAT on any other programs. Might be something to try. I'm running Win 7 on two laptops with a Flex 6500.

John, W8AGS