Modify audio on the fly, can do?

Yup, that would be a good way to go back to basics. If your source Teensy already has an audio board then you could output the analogue sine wave with that, and use your scope to compare the two. There will be a bit of lag for processing but otherwise they should be the same.

The next test would be to dive in to the audio library and tweak the incoming sample rate: line 58 of AudioStream.h sets it to 44100Hz, so you could set 44117 to emulate a Teensy 3, or 48000 to match my TV (and yours?). Upload that only to your “source” Teensy, of course :)
 
I've pushed a few changes up to my audio library branch, so sketches should be immune to the instantiation order of S/PDIF and I²S input and output objects. I think from my brief testing that this means the audio shield should now be usable with synchronous S/PDIF input.

Assuming this is all as I expect, you should note that if your system has the original 44100Hz sample rate set for AUDIO_SAMPLE_RATE_EXACT, but you feed it a 48kHz S/PDIF data stream, any frequencies generated within your processing engine etc. will be incorrect by that factor (about 8.8% or 1.5 semitones), and the audio engine will run slightly more often than anticipated (every 2.66ms, rather than every 2.9ms).

EDIT: this caught me out this afternoon ... a Teensy 4.x with an unmodified audio shield will not receive S/PDIF, because the shield has a capacitor on pin 15! You can de-solder it or cut the track (with care) and all will be well ... it's the tiny component outboard of the pins, near pin 15 and the 2x5 pin PC audio connector.
 
I read that earlier as well and have already cut that part, don't need to install a volume adjustment on the board.

My existing scope is "not much" and I am not getting actionable results with it for this. It has been fine for PWM signals but is not working for wave forms. I believe I will upgrade to another [still inexpensive] scope to help me here and going forward.

Any comments on one of these, a Hantek DSO2D15? It is "budget priced" and received decent reviews. I am looking at the "150MHz Bandwidth 2CH Dual Channel 1GSa/s 8M Memory Depth with 1CH Waveform Generator" model.
 
I don't have any personal experience of the Hantek, but I think most of the reviews I've chanced across have been OK. I splashed out on a Siglent SDS1104X-E, because 4 channels are nice to have sometimes, and I like the sequence triggering. But it's obviously a fair bit more than the Hantek...
 
K, here is where I am...

- Got a Hantek DS02D15 and have been messing with it for about a week. So far liking it a lot. A 4 chan would be nice but for this price...
- Also got an audio to SPDIF (A2S) converter.
- Also got a SPDIF to audio (S2A) converter.

For a verification test I:

- Set the Hantek signal generator to 2KHz @ 2.4v
- Sent the Hantek signal to the A2S.
- The A2S to the S2A.

Scoped the initial signal from the Hantek and the results of the S2A. The initial signal was a sine wave 2KHz @ 2.5v. The scoped signal from the S2A was 2KHz @ 1v, it looked perfect with no artifacts, 2KHz in and 2KHz out.

For the base test, I inserted the T4.1 prototype board between the A2S and the S2A (with an additional optical cable). For this test:

- I updated to your latest audio library (5 min ago).
- Recompiled and loaded a "SPDIF pass through" app (shown below) and confirmed your library was being used (via the compiler msgs).
- Connected Hantek signal generator (sine wave @ 2KHz/2,5v) to A2S
- A2S to T4.1 SPDIF in.
- T4,1 SPDIF out to S2A.
- Scoped initial signal to A2S and signal out of the S2A.

The 2KHz/2.5v in becomes 1.84KHz out (mostly, sometimes jumping to 2KHz every so often) at 1v and with occasional glitches in the signal.

To "verify" the above test I broke out a brand new T4.1, installed pins, plugged it into a breadboard w/ just a SPDIF in and a SPDIF out connector. No other components. Loaded the same program from the prior test, and then ran the test with the following:

- Connected Hantek signal generator (using sine wave 2KHz @ 2.5v) to A2S.
- A2S to T4.1 SPDIF in.
- SPDIF out to S2A.
- Scoped initial signal to A2S and scoped out of the S2A.

The initial audio signal was a sign wave of 2KHz @ 2.5v and the output signal was a sine wave of 2KHz @ 1v, it looked perfect with no artifacts, 2KHz in and 2KHz out.

The only "real" difference between the prototype board and the breadboard is I did not use the resisters/capacitors as part of the SPDIF transmitter/reciever on the breadboard as were shown in the data sheets for them. I must of messed up something there and will need to disassemble and rebuild (ir just remove them). Once done, I will retest to see if I get better results.

I don't understand the loss of frequency...

So it looks like it is currently on my to fix my "hardware". Once I get that settled and the test results are good, I can go back to evaluating the actual audio signal quality as well as your library changes.

Thanks!


Code:
#include <Audio.h>

AudioInputSPDIF3        spdif3In;         //xy=193,232
AudioOutputSPDIF3       spdif3Out;        //xy=633,316

AudioConnection         patchCord1( spdif3In, 0, spdif3Out, 0 );
AudioConnection         patchCord2( spdif3In, 1, spdif3Out, 1 );

#define LED             13
void setup( )
{
  AudioMemory( 50 );
  
  pinMode( LED, OUTPUT );
}


void loop( )
{
  digitalWrite( LED, HIGH );    // turn the LED on (HIGH is the voltage level)
  delay( 200 );                      // wait for a second
  digitalWrite( LED, LOW );     // turn the LED off by making the voltage LOW
  delay( 800 );                      // wait for a second
}

// eof

baseline image:
baseline.jpg

glitchy image:
prototype.jpg
 
Excellent, we have progress! As you say, something's wonky with test setup #1, but it's likely to be fixable.

Can you post links to your S/PDIF transmitter and receiver parts (on your Teensy setup, not A2S or S2A), and drawings of the wiring that works and doesn't? Also, use the various sample rate functions to report the incoming S/PDIF rate as seen by spdif3in, and the audio library update rate.

A quick calculation tells me that 2kHz * 44100 / 48000 = 1.8375kHz, so something is not running at the right rate... but it should be with your pass-through sketch and my revised library, especially as it runs OK on setup #2.
 
OK, now I am super confused....

I removed the caps and resisters on the prototype board (why not, the breadboard version ran this test fine) and reran the test, same [bad] results (2KHz in & 1.8KHz out). I then says to myself "I have this other T4.1 sitting right here that worked for the through SPDIF test just fine with just 3 components, why not try that chip on the prototype board". What do I have to lose? So I switch the T4.1 chips and re-run the test. I am now getting a nice clean output wave matching the 2KHz sine wave on the scope?!?!?

So there is something wrong with the other T4.1 IC? It appeared to run the rest of the program just fine as well as any other programs I loaded. This is my first SPDIF project. I am using various pins for button input and I2C output. This is not an exhaustive test but the T4.1 boots, loads any programs I have tried, and looks to run all other functions fine. So it appears the actual source of the static SPDIF out signal is that T4.1?

With this [I hope] "resolved" I will go back to the original program and add your SPDIF freq. reporting and show that [also] on the I2C (why not) and then go back to testing on an actual audio signal to verify that the static is gone.
 
That is truly bizarre! The only thing I can think of is that I've violated one of the obscure "don't touch register X while register Y is in state Z" rules, and it's one that you can sometimes get away with, on some chips.

Anyway, it looks as if you may have a solution for your needs, so long as you don't use the rogue Teensy 4.1. Any further info you can post will be a bonus, but if we don't find anything solid we may as well draw a line under this.

I'll probably have a further play and then re-instate my pull request (this time with working code!), as I think it does no harm and may be useful to some folk.
 
Hmm, this is still giving me issues, but possibly not for your use case (S/PDIF in and out). I thought I was getting I2S clocked from the S/PDIF input recovered clock, but it looks like I'm not. I've clearly done something, because instead of the big glitch every 14.58s I now get a quiet "ticking" at 17Hz, which is the difference between my S/PDIF test input sample rate of 44117Hz from the Teensy 3.2, and the Teensy 4.1's own exact 44100Hz clock.

just thinking aloud, really ... nothing to see here ... :)
 
That is "strange" yet interesting...

I have been having a good old time with the new scope and the other [cheap] audio components I acquired and can now easily generate a signal from the scope, convert it to SPDIF, route it to the T4.1, get the output and convert it to audio to hear. Can also scope the source and final signals to compare. More more "scientific" than just tweaking and trying to hear any difference!

I have noticed that my input signal which I set to 2.5v comes out of the final SPDIF to analog at 1v. Loose a LOT of volume so I patched in a final amp to boost the end data. Will get into serious "ear testing" this week to sanity check what I have done.

So far I have not has any issues with your library changes. I do get an incoming sample rate [from the audio to SPDIF converter] of 47994, consistently. Expected?

Thanks!
 
Glad it’s working for you … a decent scope does make things a lot easier, for sure!

47994 is about 125ppm out, which is a bit more than I’d expect, though I guess it’s affected by both the Teensy and the ADC crystal tolerances. If it sounds OK I wouldn’t worry about it. The Teensy 3.x can only get to 44117Hz which is even further out, and I don’t think it’s caused anyone huge issues.
 
I found an old USB audio interface with optical S/PDIF which can do 32, 44.1, 48 and 96kHz, so that’s quite a good test source. Fun times…
 
Back
Top