Stelios's note raises another point independent of sampling rate issues:
when running more than one digital mode app on the same processor, one or
both apps may be starved for CPU cycles and as a result underperform.
Given all the unknowns, I wouldn't consider a comparison between two digital
mode applications to be "apples and apples" unless the test was accomplished
on two identically configured PCs, each processing the same data stream. If
the data stream can be recorded and replayed, then of course the tests can
be run serially on a single PC.
73,
Dave, AA6YQ
-----Original Message-----
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED]
Behalf Of Stelios Bounanos
Sent: Tuesday, September 30, 2008 9:03 AM
To: digitalradio@yahoogroups.com
Cc: Tony
Subject: Re: [digitalradio] Comparing data modes
>>>>> On Tue, 30 Sep 2008 00:04:19 -0400, Tony <[EMAIL PROTECTED]> said:
>> What were the sampling rates used by each of those 5 applications, Tony?
>> 73, Dave, AA6YQ
> The sample rates were 11025 Hz for Mixw and IZ8BLY MT63 terminal. Looks
like
> 8000 Hz for DM780 and Multipsk. Not sure what's going on with Fldigi. I'm
> using the Vista version.
The MT63 modem works at 8000 Hz as Simon noted.
However, fldigi's default behaviour is to open the sound card at its
default (native) sample rate, usually 48 or 44.1 KHz, and then resample
to/from the modem rate using one of the converters from Erik de Castro
Lopo's excellent libsamplerate. The converter is chosen based on a
short speed test that is done the first time fldigi is run. On all
reasonably recent processors, that converter will be one of the "good"
SINC interpolators. It can always be changed later.
We basically did this to avoid the not too uncommon situation where a
sound card/driver combination claims to support the modem's sample rate
only to return mangled audio.
To really open the sound card at the modem frequency, which is currently
11025 Hz for Thor and DominoEX 5/11/22, and 8000 Hz for everything else,
use the Capture and Playback menus in the Audio settings. The default
value is Native (see above). Auto will try the modem rate first and, if
that fails, fall back to Native. You may want to try Auto if you know
that the OS can do better/faster resampling.
The other options in those menus are the rates supposedly supported by
the sound card. I say "supposedly" because the driver may be telling
some slight fibs here, i.e., if it reports the hardware native rates
together with those that it can resample to in software. It's almost
certainly doing that if it lists every standard rate from 8KHz up to
192KHz.
Experience suggests that we can trust the default (native) sample rate,
at least on the cards and platforms tested so far. The other rates give
audio of uncertain quality.
Anyway, if you force a rate that is different to the current modem's,
fldigi will need to resample. It will also resample, using the same
configured conveter, if the TX or RX ppm corrections are nonzero. Of
course it's smart enough to combine both kinds of resampling into one
step.
I don't know enough about Vista's audio system to be able to say what
happens if you run multiple programs that want different rates.
Possibly some of them will see slightly increased latency.
Regarding CPU usage, you should make sure that you have enough CPU
cycles for everything; maybe aim to keep the system load at < 50%.
Fldigi can tell you if it's dropping audio because the CPU is too busy
but only in debug builds; perhaps something to change in a future
version.
73,
Stelios, M0GLD.
