I'm receiving poor signal reports that would otherwise be 59 if it weren't for hiccups in the transmitted audio. QSLs seem annoyed to speak to me so it must be pretty bad. Received audio is fine except that I've noticed hiccups in it, as well, when I open the DAX control panel. It's as though it takes a massive amount of processor cycles to display the 16 bar-graphs for the 8 DAX channels, which causes audio frames to be dropped.
I'm guessing that there is a PC-latency issue here causing audio frames to be dropped somewhere along the processing chain. Therefore, I have a couple of suggestions to the software engineers.
1. First of all, dropped audio buffers should not happen! The audio buffering/processing should adapt to the conditions of the system on which it is running. If my computer doesn't provide optimal conditions, such as <1mS real-time deadlines, then fine, the penalty should be 10mS of added buffering delay (even if the additional 10mS of delay is bad for CW or other operating modes).
2. Second, why isn't there a diagnostic center in SSDR!? I am an embedded engineer and I know that diagnostics are of the highest priority in my projects - especially early in the release cycle when you are introduced to all of the things that can go wrong. For example, if my PC is causing dropped audio frames, I should be able to go to the diagnostic center and read/clear the "Dropped Tx Frame" counter and know exactly what is happening without going on air and being told I sound like crap.
Thanks, for letting me vent. Now, I'm off to find some obscure piece of HP bloat-ware. 73's.
Setup: HP desktop, Win7, AMD quad-core processor
1G network backbone, radio and PC wired