low pass filter in PC soundcard?

[Rob]

When looking at the output of a cheap C-Media CMI8768 based soundcard
(one of those tiny PCI-X cards that hold barely more than the chip,
a couple of output series caps and the connectors) I noticed there is
no low-pass filtering of the DAC output. The output when sending a
sinewave is a staircase. The samplerate was set to 48000, 96000 also
tried with similar effect.

Of course, when the signal is low-pass filtered the result again is
a good sinewave. But a random other cheap soundcard shows a nice
sinewave directly on the output.

Does anyone have expierence with the common practice w.r.t. output
filtering in soundcards? Can one expect a low-pass at half the sample
rate to be present on a typical low cost soundcard? Is is present
in some of the widely used chips and not in others?

[John Larkin]

You can hardly expect quality in a $4 sound card. Your ears will have
to do the filtering.

[Rob]

I am not talking about quality and price here, I only would like to
ask if this behaviour is typical and if there maybe are chipsets with
or without a post-DAC filter onboard.

Of course my ears don't hear the 48000 (or 24000) Hz product, it is
just something I noticed when checking the signal on a scope.

Maybe someone else noticed it and can classify the soundcard chipsets.

[Dave Platt]

Almost all audio DACs these days are high-oversampling designs
(e.g. "delta-sigma"). They generate a pulse-width or pulse-density
output stream at a rate that's a lot higher than the nominal sample
rate. In effect, much of the low-pass filtering is done digitally (by
the internal modulator). They usually include an analog
post-conversion / reconstruction filter, but the cutoff frequency for
this can be relatively high, and some chips may actually place the R-C
network for it on the chip itself.

It doesn't surprise me that a "cost sensitive" sound card may have
ignored good practice and omitted the low-pass analog filter... that
probably saved them a nickel or so, and in the race-to-the-bottom
market that might have made the difference between sales and no-sales
at the wholesale level. Most users would never notice.

It would be interesting to put the bad card's output into a spectrum
analyzer having at least a couple of MHz of bandwidth, and see just
where the stairstep noise is. If the signal is stair-steppy at 96000
samples/second, this would put the first odd harmonic up at around 150
kHz - this might or might not be low enough to give the rest of your
audio reproduction chain any difficulties.

I've seen that sort of thing done, by some fairly big names in the
consumer electronics industry. Years ago, I bought a Boca ethernet
card, and found out that Boca had ignored Appendix B in the AMD PCNet
chipset manual and had omitted most of the "critically important"
bypass capacitors recommended in the design. The card turned out to
be pattern-sensitive - there were some Ethernet packets it couldn't
received, because certain 1-and-0 patterns induced excessive ringing
and "ground bounce" in the chip's analog receiver and caused a 1-bit
misread and an Ethernet CRC mismatch. Feh. Haven't bought anything
made by Boca in the 20+ years since then.

[Tim Williams]

Oooh, run the MyScope demo on it. Should be wonderful.

Tim

--
Seven Transistor Labs
Electrical Engineering Consultation
Website: http://seventransistorlabs.com

"Rob" <nom...@example.com> wrote in message
news:slrnmv2uu3...@xs9.xs4all.nl...

[Rob]

Tim Williams <tmor...@charter.net> wrote:
> Oooh, run the MyScope demo on it. Should be wonderful.

I used a 500 MHz Tektronix digital scope.

[Rob]

Dave Platt <dpl...@coop.radagast.org> wrote:
> Almost all audio DACs these days are high-oversampling designs
> (e.g. "delta-sigma"). They generate a pulse-width or pulse-density
> output stream at a rate that's a lot higher than the nominal sample
> rate. In effect, much of the low-pass filtering is done digitally (by
> the internal modulator). They usually include an analog
> post-conversion / reconstruction filter, but the cutoff frequency for
> this can be relatively high, and some chips may actually place the R-C
> network for it on the chip itself.

The result on the scope clearly showed a staircase with interval
between the steps the same as the sample rate. Setting the sample
rate from 48000 to 96000 halved the interval. I was using a demo
program of Linux Alsa to generate the sine wave, so it generated more
points of the sine in that case and the steps became smaller.

I indeed had expected a construct similar to what you describe, but
apparently it is different on this card. Or, the filter that is present
actually filters the pulses that construct the output signal but not
the transitions between the subsequent samples.

> It doesn't surprise me that a "cost sensitive" sound card may have
> ignored good practice and omitted the low-pass analog filter... that
> probably saved them a nickel or so, and in the race-to-the-bottom
> market that might have made the difference between sales and no-sales
> at the wholesale level. Most users would never notice.

Yes, that is of course the reason.
Fortunately we have a lowpass further on in the circuit, but it is
really something to watch because we use the audio to modulate an FM
transmitter and of course there would be lots of garbage transmitted
when this signal reaches the modulator.

> It would be interesting to put the bad card's output into a spectrum
> analyzer having at least a couple of MHz of bandwidth, and see just
> where the stairstep noise is. If the signal is stair-steppy at 96000
> samples/second, this would put the first odd harmonic up at around 150
> kHz - this might or might not be low enough to give the rest of your
> audio reproduction chain any difficulties.

Yes I tried the "FFT" mode of the scope and indeed it showed a nice
comb pattern.

> I've seen that sort of thing done, by some fairly big names in the
> consumer electronics industry. Years ago, I bought a Boca ethernet
> card, and found out that Boca had ignored Appendix B in the AMD PCNet
> chipset manual and had omitted most of the "critically important"
> bypass capacitors recommended in the design. The card turned out to
> be pattern-sensitive - there were some Ethernet packets it couldn't
> received, because certain 1-and-0 patterns induced excessive ringing
> and "ground bounce" in the chip's analog receiver and caused a 1-bit
> misread and an Ethernet CRC mismatch. Feh. Haven't bought anything
> made by Boca in the 20+ years since then.

Hmm that is really bad... well, the datasheet from C-Media makes some
recommendations about PCB layout and indeed the board is a multilayer
with embedded ground plane, apparently something that does not cost as
much as it used to.
(these cards go for about 10 dollar including shipping from China)

Our problem is that we need a card that we can be certain that it has
a fixed low latency. We also used more expensive cards, but the
"sound effects" stuff included on them is implemented in DSP and
causes additional delays that vary between manufacturers and types.
So we prefer a "bare DAC".

[rickman]

A product I build uses an AK4552 CODEC which has 8x interpolation in the
DACs. You can see these "bumps" in the signals generated, but since
they are 8x the sample rate, they are not significant. Even at 8x the
sample rate, they are hard to filter with something simple and small. I
add a 1 pole roll off with -3 dB around 25 or 30 kHz (I don't recall the
exact number) just to say I have a filter. I had to bump it up once to
make sure I meet the performance spec at 20 kHz.

Consider how much filtering would be needed to significantly reduce 48
kHz with a 20 kHz passband! Not so easy in a small, simple product.

--

Rick

[rickman]

You can get low (or at least fixed) latency DACs up to a MHz or two I
believe. You can interpolate the signals digitally with no added
latency and get an effective sample rate much higher. Then simple
filtering will be fairly useful.

--

Rick

[Rob]

rickman <gnu...@gmail.com> wrote:
>> Our problem is that we need a card that we can be certain that it has
>> a fixed low latency. We also used more expensive cards, but the
>> "sound effects" stuff included on them is implemented in DSP and
>> causes additional delays that vary between manufacturers and types.
>> So we prefer a "bare DAC".
>
> You can get low (or at least fixed) latency DACs up to a MHz or two I
> believe. You can interpolate the signals digitally with no added
> latency and get an effective sample rate much higher. Then simple
> filtering will be fairly useful.

The latency of the DAC itself is not the problem, but a FIR/IIR filter
inserted between the digital output and the DAC is.

We used two different types (PCI and PCI-X) of Soundblaster Audigy
cards and the latency differed by about 200us. Both of them probably
have latency of some milliseconds.

We need all soundcards to be within 10-20us of eachother (about 1 sample).
Of course never a problem when all cards are the same, but I suspect
it will be OK as long as all cards are without extra DSP.
(as the Audigy has)

[Rob]

rickman <gnu...@gmail.com> wrote:
> A product I build uses an AK4552 CODEC which has 8x interpolation in the
> DACs. You can see these "bumps" in the signals generated, but since
> they are 8x the sample rate, they are not significant. Even at 8x the
> sample rate, they are hard to filter with something simple and small. I
> add a 1 pole roll off with -3 dB around 25 or 30 kHz (I don't recall the
> exact number) just to say I have a filter. I had to bump it up once to
> make sure I meet the performance spec at 20 kHz.
>
> Consider how much filtering would be needed to significantly reduce 48
> kHz with a 20 kHz passband! Not so easy in a small, simple product.

Fortunately we require only audio up to about 3.5 kHz. So a lowpass at
5 kHz should not be a problem.

We use the 48 kHz sample rate only to get accurate timing of the signal.
We want to output the same signal on different cards with timing equal
to within 10-20 us. This is done by variable ratio resampling of the
audio using a software PLL.

Actually I am considering to just set the card to the maximum rate
(96 kHz for these cards, 192 kHz for some others) instead of the fixed
48 kHz rate. The resampler can easily handle that, should only have
a look at some of the code and the buffer sizes.

[rickman]

How do you get timing aligned at all in two cards with separate clocks?
Even if the two units derive their clocks from a common clock, how do
you get the sampling started on the same foot? Do you measure the audio
out of the cards and adjust your software driving them?

--

Rick

[Rob]

The Alsa software can capture timestamps (in nanosecond increments)
of the interrupt that the soundcard issues when it finishes a block.

From these timestamps, the relation between the free-running sample
clock and the real time can be determined, and the audio is resampled
at a variable rate to align the actual audio output with real time.
The variable rate is slowly adjusted to get the output on-time, i.e. all
those timestamps are targetted to be the same.

Actually, the "defect" being discussed here very nicely shows this system
in operation. Because the sample clocks of the typical soundcard are
only accurate to about .01%, when putting the output from two cards on
the scope and triggering from one, it can be observed that the sinewaves
are snap on top of eachother but the samples output on the second card
slowly "wander" across the wave.

(note that the cards are not in the same system! the systems are each
time-synchronized to a GPS receiver outputting pulse-per-second. for this
test, two complete setups were installed side-by-side on the workbench,
but normally they are installed at different sites)

[rickman]

Very ingenious. That must be using some hardware function in the CPU?

> From these timestamps, the relation between the free-running sample
> clock and the real time can be determined, and the audio is resampled
> at a variable rate to align the actual audio output with real time.
> The variable rate is slowly adjusted to get the output on-time, i.e. all
> those timestamps are targetted to be the same.
>
> Actually, the "defect" being discussed here very nicely shows this system
> in operation. Because the sample clocks of the typical soundcard are
> only accurate to about .01%, when putting the output from two cards on
> the scope and triggering from one, it can be observed that the sinewaves
> are snap on top of eachother but the samples output on the second card
> slowly "wander" across the wave.
>
> (note that the cards are not in the same system! the systems are each
> time-synchronized to a GPS receiver outputting pulse-per-second. for this
> test, two complete setups were installed side-by-side on the workbench,
> but normally they are installed at different sites)

Holly crap! So there is specialized hardware for this on the sound
cards? Or is there another card in the system? I haven't seen a PC
that can sync to a 1 PPS signal.

BTW, with a cutoff starting at 5 kHz, you still aren't in a great
position to reduce the sampling artifacts so much unless you use some
good filters. Even a two pole filter will only reduce the sample rate
artifacts by 40 dB, or about 100 fold. Is that enough?

--

Rick

[Rob]

rickman <gnu...@gmail.com> wrote:
>> The Alsa software can capture timestamps (in nanosecond increments)
>> of the interrupt that the soundcard issues when it finishes a block.
>
> Very ingenious. That must be using some hardware function in the CPU?

Well, maybe the actual resolution is not nanoseconds but at least the
returned field has a nanosecond increment. The Linux clock ticks in
nanoseconds, and it uses several mechanisms included in modern PC systems
to implement that (highres timer, CPU cycle counter).
Actually I am happy when at this level it at least has microsecond
resolution.

>> (note that the cards are not in the same system! the systems are each
>> time-synchronized to a GPS receiver outputting pulse-per-second. for this
>> test, two complete setups were installed side-by-side on the workbench,
>> but normally they are installed at different sites)
>
> Holly crap! So there is specialized hardware for this on the sound
> cards? Or is there another card in the system? I haven't seen a PC
> that can sync to a 1 PPS signal.

The 1PPS sync is not related to the soundcard. The PPS pulse enters
the PC on a serial or parallel port pin, and existing software in the
Linux kernel allows the system clock to be synchronized to that.
This works the same way as the Alsa timestamp: when an edge occurs
on this pin, and interrupt is issued and the momentary value of the
nanosecond clock is put in a buffer. A usermode program reads these
timestamps, averages the offset from the 1 second mark, and slowly
adjusts the nanosecond system clock to be on-time.
In a good system at stable temperature, it keeps the system clock within
a few hundred nanoseconds, otherwise it still is within 2 microseconds
or so.

> BTW, with a cutoff starting at 5 kHz, you still aren't in a great
> position to reduce the sampling artifacts so much unless you use some
> good filters. Even a two pole filter will only reduce the sample rate
> artifacts by 40 dB, or about 100 fold. Is that enough?

Right now we are relying on the input filter of the transmitter, which
is a lowpass at 3.4 kHz but I am not sure how many poles it has.
There probably are also other characteristics of the modulator that limit
the high-frequency response. At least, we have not noticed problems
on the spectrum analyzer. But it now is something that has more
attention than it had before.

(this is a co-channel diversity repeater system for wide-area coverage)

[rickman]

When you say "nanosecond system clock" you are referring to some
software clock, not a hardware timer, right? Again, I am not familiar
with any hardware in a PC to support such an adjustable clock. I can
picture how this might be workable. Again, pretty clever I think for a
designer to convince him/herself this could work well. I'm used to PCs
being very poor at timing anything.

>> BTW, with a cutoff starting at 5 kHz, you still aren't in a great
>> position to reduce the sampling artifacts so much unless you use some
>> good filters. Even a two pole filter will only reduce the sample rate
>> artifacts by 40 dB, or about 100 fold. Is that enough?
>
> Right now we are relying on the input filter of the transmitter, which
> is a lowpass at 3.4 kHz but I am not sure how many poles it has.
> There probably are also other characteristics of the modulator that limit
> the high-frequency response. At least, we have not noticed problems
> on the spectrum analyzer. But it now is something that has more
> attention than it had before.
>
> (this is a co-channel diversity repeater system for wide-area coverage)
>

--

Rick

[Rob]

rickman <gnu...@gmail.com> wrote:
> When you say "nanosecond system clock" you are referring to some
> software clock, not a hardware timer, right? Again, I am not familiar
> with any hardware in a PC to support such an adjustable clock. I can
> picture how this might be workable. Again, pretty clever I think for a
> designer to convince him/herself this could work well. I'm used to PCs
> being very poor at timing anything.

You probably were using Windows?
Linux is much better at timing, and I sometimes hear BSD is even better.

In Linux there are several API calls to return a time in nanoseconds,
which can be things like uptime, UTC time, etc. I think the system
just keeps an offset value for all of them, to be added to the momentary
value of the "hardware" time it reads at that moment.
As those "hardware" time counters have a small wraparound interval, there
also is an extension of that in a software field.

Those details are in the kernel and not visible to the application.

The chrony time adjustment program displays stats like this:

Reference ID : 80.80.83.0 (PPS)
Stratum : 1
Ref time (UTC) : Sat Sep 12 08:23:20 2015
System time : 0.000000100 seconds fast of NTP time
Last offset : +0.000000125 seconds
RMS offset : 0.000000466 seconds
Frequency : 11.184 ppm slow

[upsid...@downunder.com]

On Sat, 12 Sep 2015 04:17:31 -0400, rickman <gnu...@gmail.com> wrote:

>> The 1PPS sync is not related to the soundcard. The PPS pulse enters
>> the PC on a serial or parallel port pin, and existing software in the
>> Linux kernel allows the system clock to be synchronized to that.
>> This works the same way as the Alsa timestamp: when an edge occurs
>> on this pin, and interrupt is issued and the momentary value of the
>> nanosecond clock is put in a buffer. A usermode program reads these
>> timestamps, averages the offset from the 1 second mark, and slowly
>> adjusts the nanosecond system clock to be on-time.
>> In a good system at stable temperature, it keeps the system clock within
>> a few hundred nanoseconds, otherwise it still is within 2 microseconds
>> or so.
>
>When you say "nanosecond system clock" you are referring to some
>software clock, not a hardware timer, right? Again, I am not familiar
>with any hardware in a PC to support such an adjustable clock. I can
>picture how this might be workable. Again, pretty clever I think for a
>designer to convince him/herself this could work well. I'm used to PCs
>being very poor at timing anything.

The x86 series processors since Pentium days have a 64 bit TSC (Time
Stamp Counter) that is incremented by each cycle of the CPU clock. You
can get a snapshot of this counter by using the RDTSC (Read TSC)
machine instruction. Doing this in an ISR and you get quite high
accuracy time stamps on an external event.

Of course there are problems due to the uncertainty of the CPU clock
(thermal dependency) and also with multiple/multicore processors.

Regarding generating system clocks that are fast/slow relative to true
time is easy. On Windows single processor, there is a clock interrupt
at 100 Hz. Nominally 100 000 is added to a 64 bit counter counting
number of 100 ns units. To run the clock fast, add 100 001 or more or
add 99 999 or less to run the clock slow. On modern Linux versions, HZ
is 1000 Hz by default, so the addend is adjusted accordingly.

[rickman]

Having a clock that returns nanosecond resolution is one thing. Having
accuracy and precision to any given level is another.

I designed a board to convey the IRIG-B time code signal across an IP
network, but to this day I am not fully aware of how they can keep the
mechanism synchronized across the network. I am amazed that the various
delays can be calibrated out with any precision or accuracy.

--

Rick

[Rob]

The above status means that the average timestamp returned at a PPS
interrupt is only about 466ns off the seconds mark. The last one was
125ns off. There could be an additional fixed offset because of the
constant time it takes to handle those interrupts, but it is not that
important in our application because it should be roughly the same on
all nodes.

> I designed a board to convey the IRIG-B time code signal across an IP
> network, but to this day I am not fully aware of how they can keep the
> mechanism synchronized across the network. I am amazed that the various
> delays can be calibrated out with any precision or accuracy.

That is why we don't use network time (NTP) for the final locking.
We use NTP only to get "coarse time" and to sync those systems that
are not transmitting nodes. The transmitting nodes are synced to 1PPS
signals from a GPSDO, that also provides 10 MHz as a reference for the
transmitter frequency.

Over-the-air measurements of installed transmitters indicate that we are
within 10us of synchronous transmission. It does not make much sense
to further improve on that (may be possible by doing everything in hardware)
because 10us is equivalent to only 3km of path length at the speed of
radio waves, so a similar difference occurs all the time due to difference
in distance from the transmitters.

[rickman]

That is one of the things that isn't so obvious to me. But if the
numbers show the interrupt response time is stable, then it must work.

>> I designed a board to convey the IRIG-B time code signal across an IP
>> network, but to this day I am not fully aware of how they can keep the
>> mechanism synchronized across the network. I am amazed that the various
>> delays can be calibrated out with any precision or accuracy.
>
> That is why we don't use network time (NTP) for the final locking.
> We use NTP only to get "coarse time" and to sync those systems that
> are not transmitting nodes. The transmitting nodes are synced to 1PPS
> signals from a GPSDO, that also provides 10 MHz as a reference for the
> transmitter frequency.
>
> Over-the-air measurements of installed transmitters indicate that we are
> within 10us of synchronous transmission. It does not make much sense
> to further improve on that (may be possible by doing everything in hardware)
> because 10us is equivalent to only 3km of path length at the speed of
> radio waves, so a similar difference occurs all the time due to difference
> in distance from the transmitters.

Then Bob's your uncle! I'd like to do more with time references. I
haven't had the opportunity yet.

--

Rick