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?
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.
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.
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.
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.
Yes I tried the "FFT" mode of the scope and indeed it showed a nice comb pattern.
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".
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.
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)
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.
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?
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)
Very ingenious. That must be using some hardware function in the CPU?
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?
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.
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.
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)
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
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.
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.