Sample alignment in I2S streams - issue still present?

Status
Not open for further replies.

audiomath

Active member
Hi folks,
Does the Teensy 4 and current audio lib still have the startup unpredictable I2S sample alignment issue?

I have a few new projects lined up for Teensy 4, and since I'll be there I thought I'd play with yet another SDR library implementation.

Thanks!
--jim
 
No idea, you've not given any way to reproduce the issue nor a reference to past thread(s) about it.
 
No idea, you've not given any way to reproduce the issue nor a reference to past thread(s) about it.

Sorry, I thought it was a widely known issue. Unfortunately, I don't have a way for any Teensy dev to duplicate this without the SDR hardware. In a nutshell, however it seems that when I2S starts up for recording, the L/R sample order appears to be "random". That wouldn't matter in the slightest for the great majority of audio apps, but anything requiring quadrature processing of the stream has to have a known L/R (or I/Q) alignment. My reason for bringing it up here is because I would like to work on a SDR project, but since the detection/workaround code methods used here aren't 100% effective and rely on specific signal content to work, I'm reluctant to invest the time if the issue can't be resolved.

Having said all that, if the dev community believes a reliable fix or workaround to be possible, I'm willing to invest some hours and hardware toward the solution. I have several SDR "front ends" in the lab and normal array of RF and digital test equipment used for this kind of development.

Specifically, there are two SDR projects affected that I know of so far:
(1) https://github.com/DD4WH/Teensy-ConvolutionSDR/blob/master/Teensy_Convolution_SDR.ino

and

(2) https://github.com/DerekRowell/AudioSDR/blob/master/DOC/AudioSDR.pdf

The latter gives a fairly concise description of the issue in Section 4.1 on Page 9, quoted here:

"Although not strictly a part of the audioSDR package, this audio block is necessary to
detect and eliminate a nasty bug in the Teensy 3.6 two channel I2S input through an audio
codec.3
The bug appears randomly (with about 50% probability) on program upload and (less
frequently) on power-up, and once present remains until a reload or a power cycle.
3I do not mean to imply that the bug is in PJRC’s software as it has been reported on many ARM MCUs
with different codecs.
9What happens is very simple: the system remains fully functional, but the samples in
the two I2S data streams from the codec become out alignment with each other,
by a single sample, or in other words a time delay of one sample is introduced between the I
and Q data. While this may be not important for many audio/music processing applications,
it completely destroys the essential phase relationships for quadrature SDR operation."

The code referred to above can be found beginning at line 73 in this CPP file:
https://github.com/DerekRowell/AudioSDR/blob/master/SRC/AudioSDRlib/AudioSDRpreProcessor.cpp


Thanks!
--jim
 
Sorry, I thought it was a widely known issue. Unfortunately, I don't have a way for any Teensy dev to duplicate this without the SDR hardware.

So I had a play with T4.0 and Audio shield D - the bug is definitely present.

I connected the L+R line ins together to a 4k7 resistor from my scope probe-calibrate square wave and looked
at the line outs. Sometimes they were synchronous, sometimes the right channel was 23µs late, on repeated
reloads with:

Code:
#include <Audio.h>


#define AMPLITUDE 0.5


AudioInputI2S            input ;
AudioOutputI2S           i2sout ;
AudioConnection          connl (input, 0, i2sout, 0) ;
AudioConnection          connr (input, 1, i2sout, 1) ;

// The Audio Shield chip
AudioControlSGTL5000 codec;



void audio_setup()
{
  AudioMemory(4);

  codec.enable();  
  codec.inputSelect (AUDIO_INPUT_LINEIN);  // assumes microphone present on Audio shield

  codec.volume(0.6);
  codec.lineOutLevel (13) ;  // turn up line out to max
}



void loop ()
{
}

void setup ()
{
  Serial.begin (115200) ;
  audio_setup () ;
}
 
Thanks! That was a quick/clever repro. 1 sample @ 44110 is 22.676us. If it's consistent then the right channel is 1 sample late when this occurs.

Now the question becomes can anything be done about it... Derek mentions in his PDF that the issue has been identified on different ARMs. That may be true, but some webcrawling this morning hasn't turned anything up yet.

--jim
 
Now the question becomes can anything be done about it...

To me it looks like ringing of the frame-sync signal. we know that on T4 there is a need to add a small inline resistor to MCLK. Maybe it is a good idea to add these resistors to all I2S lines?
 
To me it looks like ringing of the frame-sync signal. we know that on T4 there is a need to add a small inline resistor to MCLK. Maybe it is a good idea to add these resistors to all I2S lines?

To switch left and right LRCLK would have to be delayed 23us or inverted... A little ringing won't do that.
Yes the I2S bus ought to be impedance controlled like any other high speed bus, but apart from MCLK (which
many devices don't need) the timing constraints aren't particularly tight with a bit rate under 3MHz.
 
This specific bug made me crazy a few years ago while programming SDR radio software.

We termed it "twin peak syndrome", because in an SDR, you have to have a strict 90 degree phase difference in the I & Q input signals in order to see the signal as ONE signal in the spectrum display. When the "twinpeak syndrome" appears [as the posters explained, a lag of ONE sample in the audio codec], you see TWO signals in the spectrum display.

https://github.com/df8oe/UHSDR/wiki/IQ---correction-and-mirror-frequencies

According to my belief, it is NOT a feature of a specific microcontroller, but I believe it is a bug/phenomenon connected with several types of codecs.

IT IS CERTAINLY NOT A FEATURE OF THE AUDIO LIB, as stated in the original post!

I observed this phenomenon with the following combinations of microcontrollers and I2S codecs:

STM32F4 & WM8731
STM32F7 & WM8731
STM32H7 & WM8731
Teensy 3.6 & SGTL5000 [teensy audio board rev C]
Teensy 4.0 & SGTL5000 [Teensy audio board rev D]

So, my new hypothesis is, that it is a bug within several brands of codecs.

I have NEVER observed this phenomenon with T4 & ADC PCM1808a, by the way. So, for an SDR, why not try the Teensy 4.0 or 4.1 with the ADC PCM1808a module? The latter is available for a few dollars at Ebay or Aliexpress.

P.S.: This bug has been the subject of some other threads on this forum and Bob Larkin and bmillier have posted some very good code and ideas to investigate and cure that phenomenon.
 
To switch left and right LRCLK would have to be delayed 23us or inverted... A little ringing won't do that.
Yes the I2S bus ought to be impedance controlled like any other high speed bus, but apart from MCLK (which
many devices don't need) the timing constraints aren't particularly tight with a bit rate under 3MHz.

BTW, are you using the audio adapter soldered to T4?
 
"So, for an SDR, why not try the Teensy 4.0 or 4.1 with the ADC PCM1808a module? The latter is available for a few dollars at Ebay or Aliexpress."

I would consider that, thanks. That part is only an ADC, though. Not useful for a transceiver, unless I use something else for a DAC.
Using two Teensy 4 modules with separate ADC and DAC isn't even out of the question, really. I'll have to think about all this.

Still - if there's a way to fix the bug or find an acceptable workaround, SDR projects would work reliably with the Teensy Audio Board. I think that's a good goal, if possible.

Thanks!
 
Workaround1:
* Restart the Codec once you detected twinpeaks
Workaround2:
* Shift your Sample Buffer by one Sample once detected

I use the DAC PCM5102 for my setup
You do Not need two Teensy for a transceiver
 
Yes, looking for symmetry in the FFT magnitudes will work, but I'm not sure how well it will work without at least one strong signal in the bandpass.
I'll take a look at PCM5102, thanks!

This also has me wondering if the PCM3060 would work. I licensed a DSP "engine" to a manufacturer who uses that CODEC in their SDR, but since they use a USB audio transport with a Cypress MCU, the situation isn't equivalent.
 
Status
Not open for further replies.
Back
Top