Time's points are all excellent, and I agree with every one of them.
The key issue here, I think, is that this is a SYSTEM issue and there needs to
be some serious systems engineering done to solve it. The "problem" isn't in
Windows, the main board, the 1394 adapter, the 1394 driver, the flex driver, or
PowerSDR. The problem is in the SUM of all of these things.
There *are* mechanisms in Windows ranging from the driver level through the
application software level, that are specifically designed to help combat
latency ("glitching") problems. You need somebody who understands the OS
architecture to sit down and do an analysis, and attack this from a systems
perspective. THAT's the only way to solve this problem.
However, until some real end-to-end systems engineering is done, getting a
working system will only ever be hit and miss. If you have the time and
expertise to find a complete system that works through trial and error (like
Neal does), you can put together a working system. Or, you get lucky. Or both.
Another thing to keep in mind: The problem isn't amenable to the standard
driver development solutions to the "DPC latency problem". The classic
solution to this problem is to do extensive intermediate buffering. HOWEVER,
the problem with that solution would be that the overall receive latency (from
the time something kits the radio's antenna to the time that you hear it in
PowerSDR) would almost CERTAINLY BE UNACCEPTABLE. When you play back a CD or
DVD, if the audio appears four or five seconds after you hit "play" you don't
care. In PowerSDR, if the audio appeared in your speaker five seconds after
the signal hit your antenna, you'd probably be very unhappy.
That's just one reason that this is a complex problem. But it CAN be addressed
and mitigated. What's needed is an overall systems approach.
Peter
K1PGV
> -----Original Message-----
> From: [email protected] [mailto:flexedge-boun...@flex-
> radio.biz] On Behalf Of Tim Ellison
> Sent: Monday, April 26, 2010 8:31 AM
> To: [email protected]
> Subject: Re: [FlexEdge] PowerSDR 3644 Raspy audio - older versions
>
> 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
>
_______________________________________________
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.
