I have a project that uses Teensy 3.6 to acquire a half-dozen channels of sensor data and transfer the data in real time via USB Serial to a PC, where I wrote a multi-channel scrolling console to display it. One of my sensor channels is audio, and for that I use the teensy audio board. Since my serial bandwidth is limited to 3-4 Mbps and I'm primarily interested in voice-codec quality sound, I wrote a queue object that decimates the audio to 8820 Hz before applying a 256 sample FFT and transmitting everything. One of the display channels is a spectrogram of the first 45 bins of the audio signal.
All of this works perfectly (photo at bottom). Now here's my question/problem:
Periodically I also use the Teensy audio board to play a sound from an SD card. Recording continues during this playback, and until today I had thought the simultaneous recording and playback was working fine, too.
Today I connected a test microphone on a long wire that introduced more 60 Hz noise than usual. On the spectrogram (photo below) I immediately noticed that while the sound is playing, the 60 Hz / 120 Hz noise in the microphone line is shifted up by one FFT Bin, which in this case is about 34 Hz. Of course, once I noticed it in the 60Hz line, I can easily see that the same frequency-shift is affecting the actual recorded audio as well. I didn't notice it previously because I was looking at low-level periodic signals that span multiple bins in that same region.
Increasing the playback time to approximately one second it then became obvious that while the audio board is playing back sound, the rate at which audio data samples are received from the teensy drops noticeably: the scrolling displays for those channels slow down momentarily while all other channels continue to supply data at the expected rate. This is not just a delay in data transmission; there are permanently missing samples that gradually cause the audio-based channels to drift behind the other channels.
Since the 60 Hz noise source is fixed, I conclude that the frequency shift is an artifact caused by the audio board failing to keep up with its 44.1 KHz sample rate during the time when audio playback is occurring. This brings me to my question:
Before I start tearing things apart, has anybody seen this before?
Can anybody confirm that they have used the teensy audio board to accomplish one second of mono audio playback at 44.1 KHz with simultaneous recording at 44.1 KHz and NOT seen any problem with the sampling frequency on the recording? The chip documentation suggests that this should work, but there's a lot of library between me and the chip
The FFT is not coming from the Audio board -- I'm just doing that on the teensy itself, so the audio board does nothing but record, decimate, and periodically play a sound.
The sound file comes from an SD card on the teensy itself, but I think problems there should slow down the whole loop, affecting other data channels as well as the audio channel.
Perhaps I need to move decimation out of the audio library, where I've implemented it as a queue, and handle it downstream myself?
Here is an image of the console with the audio spectrogram running and an image of the spectrogram showing the obvious shift in the 60 Hz / 120 Hz recorded signal every time a sound is played.
Any thoughts about where to start looking, or how to work around this?
All of this works perfectly (photo at bottom). Now here's my question/problem:
Periodically I also use the Teensy audio board to play a sound from an SD card. Recording continues during this playback, and until today I had thought the simultaneous recording and playback was working fine, too.
Today I connected a test microphone on a long wire that introduced more 60 Hz noise than usual. On the spectrogram (photo below) I immediately noticed that while the sound is playing, the 60 Hz / 120 Hz noise in the microphone line is shifted up by one FFT Bin, which in this case is about 34 Hz. Of course, once I noticed it in the 60Hz line, I can easily see that the same frequency-shift is affecting the actual recorded audio as well. I didn't notice it previously because I was looking at low-level periodic signals that span multiple bins in that same region.
Increasing the playback time to approximately one second it then became obvious that while the audio board is playing back sound, the rate at which audio data samples are received from the teensy drops noticeably: the scrolling displays for those channels slow down momentarily while all other channels continue to supply data at the expected rate. This is not just a delay in data transmission; there are permanently missing samples that gradually cause the audio-based channels to drift behind the other channels.
Since the 60 Hz noise source is fixed, I conclude that the frequency shift is an artifact caused by the audio board failing to keep up with its 44.1 KHz sample rate during the time when audio playback is occurring. This brings me to my question:
Before I start tearing things apart, has anybody seen this before?
Can anybody confirm that they have used the teensy audio board to accomplish one second of mono audio playback at 44.1 KHz with simultaneous recording at 44.1 KHz and NOT seen any problem with the sampling frequency on the recording? The chip documentation suggests that this should work, but there's a lot of library between me and the chip
The FFT is not coming from the Audio board -- I'm just doing that on the teensy itself, so the audio board does nothing but record, decimate, and periodically play a sound.
The sound file comes from an SD card on the teensy itself, but I think problems there should slow down the whole loop, affecting other data channels as well as the audio channel.
Perhaps I need to move decimation out of the audio library, where I've implemented it as a queue, and handle it downstream myself?
Here is an image of the console with the audio spectrogram running and an image of the spectrogram showing the obvious shift in the 60 Hz / 120 Hz recorded signal every time a sound is played.
Any thoughts about where to start looking, or how to work around this?