DISCLAIMER: The opinions statements expressed here are my personal opinions and not that of FlexRadio Systems.
Here is the problem with a PC that is experiencing delay and latency that is out of specification for a real-time audio system; it isn't exclusively effecting RX - it effects TX too. Missing elements or words in CW due to dropped buffers is not an acceptable operating condition. The same goes for digital modes too where timing is of the essence. In voice, if the dropped audio buffers are on the order of a few hundred ms, then it just sounds choppy. Dropping audio buffers just isn't a realistic option for a SDR. You can not compare a FLEX-5000 +RX2 to a consumer CD audio device installed in your computer. That device is processing two (2) channels of 44100Hz audio (bit) streams. The FLEX-5000 is processing up to ten (10) isochronous 192 KHz bit streams. This is not close to a fair comparison with a CD player. What comes close is a Firewire attached multi-channel mixing console, but they are usually not running at a 192 KHz sampling rate. There are three issues here. One - This is a real-time or near real time audio processing system (PC, Firewire and software) and there will be a point where the delays are too long and it no longer is functioning within acceptable operating parameters. There is NO software fix that will correct excessive system latencies on the fly - this is a system (software & hardware) problem. If the system is not capable of operating without latencies that exceed this threshold, there is noting you can do except fix the system. You can slow down time in the vicinity of a black hole, but if you are that close you have other bigger problems than playing ham radio. :-) Two - As noted in #1, there is a threshold of system latency, once reached, you can not do anything about and the system stops performing to specifications. Before you reach that threshold point, where the system is operating in a high latency condition, but not failing completely, the software (driver in this case) must be smart enough to properly handle and buffer the delays to maintain proper audio characteristics so the system performs as designed and expected. This I believe is the point Drax is making that raspy audio is not indicative of the driver handling this pre-failure threshold condition properly because it is distorting the audio. He is making a valid point. Three - When your system is experiencing latencies where it is operating in that area where the driver is having to do a lot of buffering and recovery operations due to excessive system latencies, this should not be an area where you operate the radio normally. You do not want to be near the threshold limit because there is not enough "headroom" to handle the occasional extra long latency event. This is the point Brian is making. Right now, when the Firewire driver hits a fault condition and the audio becomes raspy, this is the equivalent of a car's "check engine light" coming one telling you something isn't quite right with the system and needs to be addressed. That activity is optimizing your PC to reduce system latencies by updating drivers and BIOSes, removing or not using resource consuming applications while operating a real-time audio processing application (like PowerSDR) or upgrading your hardware. I want the driver to handle thing properly in the "danger zone", but I also want my real-time audio processing system to normally have system latencies low enough that I do not have to invoke the "danger zone" driver logic. IMHO, both Drax and Brain are correct. -Tim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Drax Felton Sent: Sunday, April 25, 2010 8:35 PM To: 'dj' Cc: [email protected] Subject: Re: [FlexEdge] PowerSDR 3644 Raspy audio - older versions True they may buffer quiet a bit. But the SDR can just hiccup the audio and start at the current time. Essentially ignoring what was lost during the event's delay... Or any other solution rather than forcing me to shutdown and restart. -----Original Message----- From: dj [mailto:[email protected]] Sent: Sunday, April 25, 2010 8:22 PM To: Drax Felton Subject: Re: [FlexEdge] PowerSDR 3644 Raspy audio - older versions But you are right to bring up problems with PSDR 2. It's out there for us to test and ferret out problems. More so if it appears to be a driver issue. However, comparisons with satellite TV and CD players are off the mark. Those devices buffer several seconds of signal so they can stop and recover without running out of signal. I'll bet they do that far more than we actually detect because they usually can do it before the buffer empties. Can you imagine the latencies we would be seeing if PSDR buffered everything before passing the audio along? dj W6CAK _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software. _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software.
