No, I don't think we have SRC going on here.
With a bit of in-depth analysis, I can now describe what the exact symptom is.
It looks like a numerical/math problem somewhere in the chain, most likely in the Windows mixer and related to dithering (please do the suggested checks with REW, 0.1dB headroom and WASAPI exlusive modes).
On average, the output file (recording of loop-back) is systematically 0.5 bit levels too low once the input file is beyond positive half full-scale (+0.5), and it is similarly 0.5 bit levels too high for negative values below negative half full-scale (-0.5), but with a 0.25bit intermediate offset at the transition.
(Bottom trace is the difference signal amplified so that 100% represents one bit level)
This now explains
a) the ever so slightly lower level of the output
b) the residual distortion
That's why we see both the fundamental and the distortion components in the difference signal.
That certainly doesn't look right to me.
The full scale level does not reach 0dBFS, the noise floor is too high and the distortion components are too large as well (but at least match in relative levels)
Sounds like a float->int cast in C, which uses truncation by default rather than rounding. Very odd. Also wondering how you can have half a bit of error in a digital signal(!)
My FFT is filtered with a very narrow filter. I adjusted the gain to place the fundamental near 0dB. The noise floor is in the right place for 5 seconds of 24-bit audio.
Ed
Last edited:
Dithering is the answer. It allows to create signals like a -170dBFS sine in 24 bit resolution which means it is more than 20dB below the lowest bit level.
And yes, some kind of truncation wrong use of floor()/ceil() etc could be the answer for the error. It could be a scaling that went wrong, because if the Windows Mixer does re-dither the signal which could already span the whole 24-bit integer range they might have scaled it by 8388606 / 8388607 = 0.999999881 so they have room for one more bit at the peaks for dithering.... and that scaling went wrong for same reason.
Last edited:
All I can say that I can trust REW's FFT 100% and that any other professional software capable of a 64bit floating point FFT will give the exact same results than REW's. Like MultiTone, FlexAP, Acourate etc etc.
The noise floor in the data is one bit of dithering which can be easily shown by subtracting L and R channels of the source file (recorded file as well, btw). Together with the FFT gain for a 256k FFT the noise floor in the plot can be shown to settle well below -180dBFS (with a bit of FFT magnitude averaging) just like you see in my plots.
Unless you disclose exactly what you special processing is etc we can only speculate what went wrong. But it is wrong, that's 100% certain.
Coming back to this, do mean you've used a 1kHz notch filter? If so, you should have stated that explicitly in the plot (how many dB of attenuation) and of course you must not adjust the level to keep the absolute levels of the noise floor and the distortion components at the correct values.
@KSTR >(please do the suggested checks with REW, 0.1dB headroom and WASAPI exlusive modes).
My results of trying REW unfortunately differs from
https://www.diyaudio.com/community/attachments/1732134971225-png.1382971/
The shelf produced by low points FFT with Hann is pretty reproducible, but I can't see the harmonics you observed probably because of the high noise floor even on the same WAV files (REW 5.31.3) What kind of FFT settings you used? I have tried almost everything without a luck. All the harmonics (if any) are drowning in the noise. Looks like I need to start from your results first. Specific averaging/smoothing?
Also I haven't found a way to combine/merge several spectra into a single image (to send to you for instance). I'm definitely missing something important in the use of REW. Could you please assist
My results of trying REW unfortunately differs from
https://www.diyaudio.com/community/attachments/1732134971225-png.1382971/
The shelf produced by low points FFT with Hann is pretty reproducible, but I can't see the harmonics you observed probably because of the high noise floor even on the same WAV files (REW 5.31.3) What kind of FFT settings you used? I have tried almost everything without a luck. All the harmonics (if any) are drowning in the noise. Looks like I need to start from your results first. Specific averaging/smoothing?
Also I haven't found a way to combine/merge several spectra into a single image (to send to you for instance). I'm definitely missing something important in the use of REW. Could you please assist
Very probably. SA9227 has 51-family MCU inside and performs SRC
KSTR - I am using an energy-conserving averaging of the FFT bins in the frequency domain. This kind of filtering ("smoothing") is used for measuring a continuous spectrum. I made the filter very narrow to minimize spreading out a pure tone, but I see that the narrow filter is not as good as no filter.
The linear filter should not affect the relative amplitudes of the fundamental and harmonics.
Ed
The linear filter should not affect the relative amplitudes of the fundamental and harmonics.
Ed
I find no information about SRC in the SA9227, neither in the datasheet stub nor anywhere else. Where does the information come from? And what input rates are resampled to what I2S rates and back?
SRC is not trivial but there are several ways to check if SRC is present or not:
- use a sine with lower amplitude than 0.5 (like -7dBFS or so) and repeat you test, I would bet the distortion is competely gone (which no known SRC would be able to do). Don't forget to put a marker pulse at the start of file so stuff can be properly aligned. That applies to any test signal used, in order to make difference tests possible.
- use periodic white noise and check spectrum, using different sample rates.
- use a signal that has intersample overs (like fs/4 sine full-scale samples with 45degrees start offset) which usually wreck sample rate converters
Probably easiest would be I create a file for playback, and you then post the recording of the loopback and then I can proceed with REW and document the results etc.
What player and what recorder software do use, or are you working in a DAW like Reaper? And once again, what drivers or driver modes are used? Only WASAPI exclusive and ASIO are OK for this.
From the common sense and the chip possibilities (MCU). Software side input rate is determined by the driver by choosing from the list of availables (there is a vendor control panel for that), but the physical input rate can be any in the wide range of supported. That means an SRC.
In my case 48k is on in and out (physical connection). What comes from/to the software side…. I don’t know a trusted way to check, hope it’s exactly as in the control panel
Actually the problem is I can’t see https://www.diyaudio.com/community/attachments/1732134971225-png.1382971/
as you saw by REW from the same in.wav and out.wav. I’m loading the WAVs in REW’s (5.31.3) RTA window directly and see the noise at the level much higher then you. Should I use an external player? Or special smoothing/averaging not available in the evident REW/RTA configuration? How could I eliminate the difference between (yours and mine) FFT results from the same WAV files?
After I have the same FFT from the same WAVs, I will be able to continue adjusting levels etc etc and be sure that everything is correct on the measurement side at least
Sure, it's clear, but I'm loading WAV files into REW/RTA window directly, no sound card is required for that at all.
That doesn't make any sense to me.
USB driver tells the chip a sample rate to use, and the chip then selects the proper oscillator (one for 44.1k*N and one for 48k*N) and divider (for N) for I2S Clocks. In slave mode (if there is any), the external I2S clocks must match the selected rate, of course.
Further, SRC eats a lot of DSP power and a lowly 8051 MCU core (8-bit controller from 1980) is unlikely doing any SRC, even when running at a high clock frequency.
Lastly, if the chip could do SRC they sure would have advertised it in the datasheet as this is a quite prominent feature.
REW settings are:
Thank you! "use 64-bit FFT" was causing the difference. My plan is checking -0.1db (or lower) level for the harmonics influence. And then I'll be trying to verify SRC presence. Eventually I'll be able to find an independent I2S source to use as the input for the SA9227. But it's still foggy for me to verify the finally received sample rate at the software side (i.e. after the driver). Any ideas? The datasheet is too weak/short/laconic to mention SRC or so, modern 51-family MCUs (not ancient 8051 exactly) are powerful enough, driver may perform SRC as well. Anyway I'll try to verify if you don't mind
Wasapi exclusive & ASIO in windows as well as alsa hw:X in linux do no resampling. If you request 48kHz, they will run the chain at 48kHz.
Also you can capture USB packets with wireshark and check that the actual data stream has correct bitrate (just by watching the payload size of USB packets). Also you can, with a bit of scripting, extract the audio data from the captured USB packets and reconstruct the incoming audio stream on the USB level, and even play it back.
@phofman
Guess It would be too complex, on USB level I would see incoming and outgoing isochronous traffic at once with a lot of servicing information. It would be hard to parse the data, until there is a special tool for that to show the wanted parameters only. On the other hand, the lowest available for applications level is WSAPI. I hope there a related diagnostic tool (WSAPI hook based for instance) that would show the data parameters. Are you aware of any like that?
Last edited:
@KSTR
But if I switch “Lock generator to RTA FFT” on, all the harmonics disappeared completely, pure noise at the low end. And no harmonics appeared with the input level variation.
That IMHO means there is probably something foggy in FFT windowing.
So FFT specifics is rather than SRC involved into in.wav spikes
Moreover while I was trying to reproduce FFT from in.wav with precisely your settings I observed a bit different result (the same harmonics of course, but different noise curve width below -180db) To get exactly the same spectrum I had to decrease FFT size to 8 – 16k from yours 256k.
That also confirms there is something strange in FFTs of different REW versions.
Finally I’ve made the experiment for understating harmonics in in.wav. That’s curious. REW/WSAPI/48k on the loopback shown nearly the same absolute harmonics level varying input level from 0db, -0.1db and lower up to -40db (the lowers was not tried).
But if I switch “Lock generator to RTA FFT” on, all the harmonics disappeared completely, pure noise at the low end. And no harmonics appeared with the input level variation.
That IMHO means there is probably something foggy in FFT windowing.
So FFT specifics is rather than SRC involved into in.wav spikes
Moreover while I was trying to reproduce FFT from in.wav with precisely your settings I observed a bit different result (the same harmonics of course, but different noise curve width below -180db) To get exactly the same spectrum I had to decrease FFT size to 8 – 16k from yours 256k.
That also confirms there is something strange in FFTs of different REW versions.
It's quite simple to filter out the required packets and check their payload size, the data packets are easy to distinguish. All it takes is just try it and learn. Doing low-level troubleshooting takes that, no ready-made tools for low-level single-purpose tasks.
There are scripts that parse the wireshark pcap captured data, it takes again searching and learning. But if you need only the rate info, the payload size times packets per second is simple.
I have not seen yet any windows debugging which shows information comparable to linux alsa /proc/asound information . Linux is often the best tool to troubleshoot your USB device (or any audio device, provided there are alsa drivers for the given device available). Again - it takes searching and learning, as every advanced activity above basic-level use.