asynchronous board synching

Status
Not open for further replies.
Just a wild guess.. maybe 1073739000 (0x3FFF F4F8) is a good value. It's a multiple of 24 and 1000, thus allows 0%error for all std frequencies and maybe the PLL can lock a little bit faster due to the multiple of 24(?!)
Does this make any sense? I have no Idea about the inner workings of digital PLLs...

even 123456.78 Hz turns out correctly
 
Last edited:
> allows 0%error for all std frequencies

More precisely, 0% error from the source. But a crystal source always has error, so all you can ever do for the absolute rate is "close enough". Ie, a big denominator is clearly a good idea but the exact value may make no practical difference.

Be sure to cover spdif too.
 
Yup, so it does play not a big role. There is no reason not to use a high value, right? :)

Interestingly, the time to lock is always the same...and very short - about ~50..55 (minus cycles for overhead) cycles? if you don't stop the pll.

Code:
    c = ARM_DWT_CYCCNT;
    while (!(CCM_ANALOG_PLL_AUDIO & CCM_ANALOG_PLL_AUDIO_LOCK)) {}; //Wait for pll-lock
    t = ARM_DWT_CYCCNT - c;
is this correct?
Edit: Another reason could be, that the lock bit is always set if you don't stop the pll..
Edit: Yup, that's the reason. The Lock-bit stays set. Need to find an other way to measure..

Edit: Thank, Paul for you answer!
 
Last edited:
...with switching the PLL off/on it takes ~450 microseconds to lock. I don't think it will lock much faster without off/on.
~450us can be quite some time.
1 sample at 44100Hz takes 22.68us, ~20 samples ... :-(
On the other hand, they are not lost, but will just have wrong timing.
 
He wants to add decimals != zero
i.e. 44100.3456789

I don't how how that can help (Edit: Even if he changes the code not to use an int). Esp. with the temperature sesivitiy of crystals. two crystals.
And how exactly he transfers all the fast i2s signals over the air.
synchronously.

all too magically for me :) I'm out.

have fun :) i hope you can get it to work. pls. report back!

Its only transmitting raw data. I am transmitting a 32bit word (left & right together), 16 bit quality of course, at 48k and I'm using 16 buffers at a time in one packet
 
There is no magic going on .. decimals are ignored :)
They are just not needed here, because it was intended for std sampling-freqs.

Well, changing that int to a float and changing the denom to 10000000 has now given me access to those decimals. Currently at #define AUDIO_SAMPLE_RATE_EXACT 48000.814f

no more sliding clocks now.... so now i need to experiment with changing the PLL on the fly and see what happens
 
@All:
The famous clock-tree diagram indicates, that it may be possible to use - in addition - the video-pll for audio.
Maybe we can just toggle between both PLLs.
This way, we could reach a minimum time to switch the frequency.

-> if audio-pll is in use, start video-pll with the exact frequency, wait for lock, switch to video-pll.
-> vice versa.
I'm not aware of anything that uses this PLL.

But not today..I can try tomorrow.... or maybe one of you want to test that.
 
> no more sliding clocks now

Just to be clear, your clocks are still sliding. But perhaps at such a low rate that you don't care.
 
Now we need a PTP like protocol to exchange clock rate information between hosts. Preferably one that is flexible about what the transport is. Serial, RF, ethernet, hardware pin, etc. Is there something out there? tinyptp?
 
correct, but i have gone in close on the scope and messed with the numbers till I cant see any more movements
 
@Paul, i've played a bit with it.
There are no audible effect - at least I can hear none - if the steps are small.
You *will* hear clicks, if you need to change one of the other variables: n2, or c0.

This is not needed in the range 43800 .. 45200 Hertz. So there is more than enough room to adjust the samplerate without artifacts. The steps need to be small, but not *that* small.
I just tried 10Hz, which is quite much, and could'nt hear problems.

So, i guess, that means we can use this for USB.

damo: Sorry for hijacking your thread!
 
Last edited:
damo: Sorry for hijacking your thread!

Please do not apologise. I'm learning a heap. If my issue can trigger a wider conversation about something. I'm all ears.

also, approx 46900 - 48550 Hz , C0 does not change when C2=10000000 so there is a wide range there too.
 
I see the clock setting code in these files. So IMO, yes, it should be consolidated into a single function. Using a double.

./avr/libraries/Audio/output_mqs.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_i2s.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_tdm.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_i2s2.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_pt8211.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_spdif.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_pt8211_2.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_spdif2.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT;
./avr/libraries/Audio/output_tdm2.cpp: int fs = AUDIO_SAMPLE_RATE_EXACT; //176.4 khZ

I'll write some code to calculate the ratio between two clock sources (eg, teensy internal audio and fixed rate packets coming from another teensy or a PC).
 
When doing this kind of PLL adjustment to sync two clocks that both nominally should run at 44100Hz, I think it would be a mistake to say that the AUDIO_SAMPLE_RATE_EXACT has changed, it is still the rate we are aiming for, the fact that the rate between the base crystal and the audio clock has changed does not change this fact, just my two cents.
 
I could see a use for an AUDIO_SAMPLE_RATE_NOMINAL that would always be 44100, 48000 or etc.
 
What would AUDIO_SAMPLE_RATE_EXACT be then, given that clocks and PPL's are drifting and trimmed, their exact values unknown ?
 
It could be "what the teensy clock registers are going to be initially set to". Which, glancing at AudioStream.h, is already sometimes a non-integer number.
 
I found an other nice thing to work on :) and will not work on these things here.

So, whatever you do with USB or other things.. maybe we should try to find a better way, which would allows to sync more sources... a nice, good working algorithm that inserts/removes samples + filtering instead of playing with the PLL / clock. Or something completely different.
I imagine a usb-audio as "soundcard" with the USB-Host, or S/PDIF... as I2S is the "hearbeat" of the Audio-library, there is a big chance that it will produce more problems that it solves (for future features)
 
I have some code working that will take a periodic input from any source at any frequency and adjust the teensy audio clock to match it. For example, I'm syncing to a PC sending a single byte via serial every second. Send me a private message if you are interested in alpha testing.
 
I have a philosophical question about clock sync. Which is better for teensy related, separated audio clock use cases?

a) just match rates
b) match rate and phase (like a PLL). If clock A is slightly slower than clock B, you need to speed A up to be faster than B to make up for lost time, then shift to what is hopefully the same rate.
 
Status
Not open for further replies.
Back
Top