Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 20 of 20

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

  1. #1
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187

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

    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:
    
    }

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    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)

  3. #3
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.
    Attached Files Attached Files

  4. #4
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    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 by Frank B; 01-08-2017 at 09:30 PM.

  5. #5
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    Click image for larger version. 

Name:	spdif.png 
Views:	88 
Size:	17.1 KB 
ID:	9394

    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 by Frank B; 01-13-2017 at 08:02 PM.

  6. #6
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  7. #7
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    Quote Originally Posted by bmillier View Post
    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.
    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 Frank B; 01-08-2017 at 11:27 PM.

  9. #9
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  10. #10
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,551
    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).

  11. #11
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    One downside is that audiofiles - most are 44.1kHz - need recoding. (Wav),
    (mp3+aac, too)
    Maybe, this is not the only reason.

  12. #12
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  13. #13
    Senior Member
    Join Date
    Feb 2013
    Posts
    563
    Quote Originally Posted by Theremingenieur View Post
    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).
    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").

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,314
    Quote Originally Posted by Frank B View Post
    One downside is that audiofiles - most are 44.1kHz - need recoding. (Wav),
    (mp3+aac, too)
    Maybe, this is not the only reason.
    Yes, that was exactly the reason. The vast majority of MP3 & WAV files are 44.1 kHz material.

  15. #15
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    @ 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.

    Click image for larger version. 

Name:	20160709_720137.jpg 
Views:	54 
Size:	131.7 KB 
ID:	9388Click image for larger version. 

Name:	20160709_720418.jpg 
Views:	81 
Size:	131.6 KB 
ID:	9389

  16. #16
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    Just for reference, do you know you can change the frequency at runtime?
    Sorry, that i did not mention it earlier ;-)
    https://forum.pjrc.com/threads/38753...he-sample-rate

    (not tested with S/PDIF, but i guess it will work)
    No need to patch the library-sourcecode.

  17. #17
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  18. #18
    Junior Member
    Join Date
    Aug 2015
    Posts
    8
    Out of curiosity, what part are you using for the toslink connector? I was trying to avoid the cable on led situation

  19. #19
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    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.

  20. #20
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,203
    Quote Originally Posted by bmillier View Post
    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.
    This is Pauls adapter-board. I have one, it is perfect.
    https://www.oshpark.com/shared_projects/KcDBKHta
    Last edited by Frank B; 03-29-2017 at 11:19 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •