clicking noise interference (at higher frequencies) on SPDIF output T3.2 or T3.5

Status
Not open for further replies.
bmillier

bmillier

Well-known member
I am feeding the SPDIF output (thru the proper electronic circuit) to the Coax SPDIF input of my Moto 828MK3 digital mixer. The output is completely quiet if I am not sending any signal through. However, as soon as I send a high pitched (2500 Hz for example) sine signal through, there is a pronounced, steady clicking noise at a rate of around 3-5 Hz. This doesn't show up at lower frequencies. The problem isn't really apparent if I send out a music file using the SDcard port on the Teensy, but I think the clicks are just being masked by the nature of the music itself.
I thought it was my code but I can reduce the program to just the sinewave audio block feeding directly into the SPDIF output block (2500 Hz amplitude 0.5). It does this on both a T3.2 and T3.5 board. I tried powering the Teensy with a 5V USB adapter (instead of just plugging it into USB socket on the computer) to eliminate any ground loop that might be occurring. This made no difference.
I can 'scope the SPDIF output and see that the waveform is clean and at the right SPDIF amplitude of 500 mv PP, but can't analyse the data using just a scope.
I thought that the SPDIF routines might be getting interfered with by the audio routines running in my program, but this isn't the case as I am now only using one sinewave and SPDIF out blocks for this test.

I assume my Moto 828MK3 SPDIF input is working OK, but I don't have another SPDIF source to try out.
I recorded a sample of this in a .WAV file, but the forum upload routine won't accept it.
Anyone else experienced this? Thanks.

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveformSine   sine1;          //xy=270,276
AudioOutputSPDIF         spdif1;         //xy=510,278
AudioConnection          patchCord1(sine1, 0, spdif1, 0);
AudioConnection          patchCord2(sine1, 0, spdif1, 1);
// GUItool: end automatically generated code


void setup() {
  // put your setup code here, to run once:
AudioMemory(8);
sine1.amplitude(0.5);
sine1.frequency(2500);
}

void loop() {
  // put your main code here, to run repeatedly:

}
 
During development, i used a 1000Hz sine and a old, but high quality Onkyo receiver via optical link - it worked without issues (Teensy 3.2)
 
Thanks Frank. I don't hear any clicking at that frequency. But it becomes quite noticeable at > 2 KHz sine wave.
I bought an optical module to use with Teensy's SPDIF output, and then realized my mixer had only coax SPDIF input. The mixer does have other optical inputs, but they presently set for ADAT protocol and are hooked up to other units in my studio.
I zipped up the sample WAV file and the uploader takes that so I attached it.
This is such an unusual symptom that its hard to see how driver software could cause it, but I'm unsure what to try next. The Teensy board I have with the optical module on it is socketed for a T3.2. I don't have a spare T3.2, but I could steal one from another project, re-configure my mixer so its optical inputs are Toslink(SPDIF) instead of ADAT, and try again.
Thanks for your response.
 

Attachments

  • teensySPDIF.zip
    445.5 KB · Views: 112
Hm, that's an interesting effect. I can hear the "clicking".
Do you have "Audacity" or an other soundeditor that displays the waveform ? - Well, i can hear it, but the waveform looks very good (!?)
I'm not sure what it is - but the file is 44100 hz - teensy output is 44117, so whe have a small error here. Can this be the reason ?
We could try to adjust the SPDIF to 44100Hz (just for the test), to see if it's better then. (I guess, your mixer tries to sync the different sources, and 17Hz difference is a bit off and might be a bit of spec)

I can't test it at the moment because my Onkyo is back in the living-room where we need it (and moving it to my hobby-room would mean a big decrease of WAF (=Wife Acceptance Factor)), so it may take some time..
 
Last edited:
spdif.png

Here's the FFT (calculated by Audacity from your wavefile) - there's a peak at 17 Hz.
I'm not sure where the other peaks come from.
 
Last edited:
My digital mixer (connected to my PC) does have an "oscilloscope" and "FFT" capabilities. I don't see anything weird on the scope.The FFT looked good- I didn't see any small amplitude "spurs", although they were probably off the scale on the left hand side, as the freq. is so low. But, I think you have a point about the clock. I knew this was a problem with the Teensy USB on Macs. Didn't really think about it much for SPDIF, as I figured it was a self clocking protocol.
But, your most recent post just arrived and that 17 Hz figure is suspiciously equal to the difference between Teensy SPDIF and the official 44100. I just checked out the manual for the mixer, and I can set the sync from internal (44100) to slave to the SPDIF input signal. That will probably cure things, but I'll have to think whether it will screw up my other devices. Seems I read on the forum that there was a way to change the Teensy clock divisor chain to produce exactly 44100, but I'll have to check that out.
As usual, you are quite the expert on these matters Thanks a lot.
 
Hi Frank- Back again. You were right- it was the s.rate mismatch. When I configured the mixer to sync to SPDIF, the problem disappeared. But, I wanted the Teensy s.rate to be correct, and not depend upon mixer re-configuration.
So, I patched lines 304,305 in your spdif.cpp from 2,17 to 147,1250. This fixed it for 96 MHz. I also did lines 310,311 from 8,85 to 205,2179 which corrected it for 120 MHz, which is what I am using on the T3.5.
I also see that output_I2S.cpp is using the original mult/divisors, so I changed those as well in my local copy. I don't know why Paul hasn't changed the audio library to reflect this fix, as dturner did submit it on github back in october.
For that matter, some of the fixes that I have reported for problems I have found/solved in other audio lib. files (apart from one that you submitted a PR, on my behalf) have not been made either.

@donturner-- thanks for this fix- I had seen your post before, but not owning a MAC, hadn't seen the need of it - til now.
 
bmillier said:
Hi Frank- Back again. You were right- it was the s.rate mismatch. When I configured the mixer to sync to SPDIF, the problem disappeared. But, I wanted the Teensy s.rate to be correct, and not depend upon mixer re-configuration.
So, I patched lines 304,305 in your spdif.cpp from 2,17 to 147,1250. This fixed it for 96 MHz. I also did lines 310,311 from 8,85 to 205,2179 which corrected it for 120 MHz, which is what I am using on the T3.5.
I also see that output_I2S.cpp is using the original mult/divisors, so I changed those as well in my local copy. I don't know why Paul hasn't changed the audio library to reflect this fix, as dturner did submit it on github back in october.
For that matter, some of the fixes that I have reported for problems I have found/solved in other audio lib. files (apart from one that you submitted a PR, on my behalf) have not been made either.

@donturner-- thanks for this fix- I had seen your post before, but not owning a MAC, hadn't seen the need of it - til now.
Click to expand...

Glad that it works now.

But, the 17 Hz off are intended. The reason ist, that no valid divisor for exactly 44.1kHz for the ADCs/DACs is available, but they have to be in sync with I2S if both are used. 44117Hz are valid for both.
So, with your patch, you can't use the ADC's or DACs for the audiolibrary.
 
Last edited:
By ADC and DAC, I guess you mean the teensy internal ones. They much faster than 44100, but I haven't looked at the code that drives/times them, so I'll take your word that they can't do 44100 exactly.
But the SGTL5000 on the audio shield calls for a MCLK of 256* sample rate. For 44100, this is 11.2896 MHz. That is what you get with the mult/divisor figures I quoted.
I haven't found the internal ADC /DAC good enough for my purposes and only use external I2S codecs, or DACs or in this particular case the SPDIF port. So, the patch is perfect for me.
 
That's a basic question about which I've been thinking for a long time. Why was the audio library built around 44.1kHz CD standard instead of the 48kHz DAT standard. Most, if not all digital AV devices accept both, and the divisor precision question wouldn't arise as long as we can get F_BUS at 48MHz (pdb_mod=999) or 60MHz (pdb_mod=1249).
 
One downside is that audiofiles - most are 44.1kHz - need recoding. (Wav),
(mp3+aac, too)
Maybe, this is not the only reason.
 
Yes- that is the reason why I left my mixer set at 44,100 (it also does 48 and 96 Khz). At the end of the recording/mixing, it was ending up on CDs so it made no sense for me to have to do a sample rate conversion at the end of the process.
That said, currently I could probably switch over to 48 KHz, as I don't mix down to CDs much anymore.
I still haven't looked into the library code to see why the available mult/divisor ratios that can be used to provide the EXACT 44,100 for I2S and SPDIF , could not have been used to time the whole audio library framework. Frank says that the internal ADC and DACs are based on this 44117 Hz clock, and won't work when I change the I2S or SPDIF to exactly 44100.
 
Theremingenieur said:
That's a basic question about which I've been thinking for a long time. Why was the audio library built around 44.1kHz CD standard instead of the 48kHz DAT standard. Most, if not all digital AV devices accept both, and the divisor precision question wouldn't arise as long as we can get F_BUS at 48MHz (pdb_mod=999) or 60MHz (pdb_mod=1249).
Click to expand...

IIRC that had to do with jitter/quality of the MK20's MCLK at various I2S_MDR_FRACT settings (see here) and downstream: "If you set I2S_MDR_FRACT to anything other than 0 or 1, the MCLK output is terrible").
 
@ mxxx: At the link to Pauls earlier post, the "terrible" output is present when the MCLK is derived from the 16 MHz clock -not the 96 MHz PLL that the audio library uses. That is perfectly normal- you can't easily generate a 11.289600 MHz clock from a 16 MHz clock (without a PLL or similar circuit) apart from using a fractional "n" divider ( which is what the Kinetis MCU's use for the I2S block). Fractional "n" dividers work by dividing my "n" some proportion of the time and N+1, for the rest of the time, where N and that proportional term are what is used to get the exact "Average" frequency.
I took scope readings of the MCLK output for a 96 MHZ Teensy using the original MULT/DIV ratios in the audio library: 2,17 (producing a sample rate of 44,117) and also for the ratios (147,1250) that I used to get exactly 12.89600 MHz (needed for a sample rate of 44,100 exactly)
Both waveforms are 50% duty cycle, and there is similar "jitter" in both, due to the nature of the fractional "n" divider used in the I2S clock block. Each one produces the expected exact and stable clock frequency when I read them on my 10 digit frequency counter.
So, using the 147,1250 ratios perfectly solved my SPDIF problem (the subject of my original thread), and the measurements I have taken would support this. I can only assume that Frank B is correct in his statement that 44117 was chosen, instead of the standard of 44,100 sample rate for other reasons beside the I2S or SPDIF peripherals themselves.

20160709_720137.jpg20160709_720418.jpg
 
Thanks Frank. I hadn't considered it, but I suppose I could just add the line
I2S0_MDR = I2S_MDR_FRACT((MCLK_MULT-1)) | I2S_MDR_DIVIDE((MCLK_DIV-1));
with my preferred MULT/DIV values.
But, then I would have to remember this little detail when I try something else (with SPDIF) months later. I have made 4 or 5 "patches" to various audio libraries to suit my custom purposes, so I do have the extra complication of restoring these files when I do a TD update, unless I turn off the audio lib download option ( but then I get no important updates to that library in general).
Thanks for the thread link about the other complications involved in changing the sample rate. I haven't read it all yet, but I could certainly see big problems going to 48KHz or those lower rates like 11050. But, I did see references to using the I2S MCLK generator to time the DMA routines for the other functions. That is how I imagined the library was done originally, but I admit I hadn't dug through all of the code to know what was involved.
In any case I am really happy my T3.5 project, using SPDIF, is now working perfectly.
 
Out of curiosity, what part are you using for the toslink connector? I was trying to avoid the cable on led situation :)
 
I bought a Toslink transmitter module with the electronics included- Digikey 1080-1434-ND
When I weeded thru all the cables on the back of my mixer, I realized the SPDIF IO were not optical but RCA coaxial.
So, I couldn't use the module in the end. Wasn't too hard to get the SPDIF coaxial signal from the teensy output- just a few parts.
 
bmillier said:
I bought a Toslink transmitter module with the electronics included- Digikey 1080-1434-ND
When I weeded thru all the cables on the back of my mixer, I realized the SPDIF IO were not optical but RCA coaxial.
So, I couldn't use the module in the end. Wasn't too hard to get the SPDIF coaxial signal from the teensy output- just a few parts.
Click to expand...

This is Pauls adapter-board. I have one, it is perfect.
https://www.oshpark.com/shared_projects/KcDBKHta
 
Last edited:
Status
Not open for further replies.
Back
Top