Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 71 of 71

Thread: asynchronous board synching

  1. #51
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,898
    Quote Originally Posted by Frank B View Post
    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 by WMXZ; 11-27-2020 at 02:14 PM.

  2. #52
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    > 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.

  3. #53
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    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 by Frank B; 11-27-2020 at 02:55 PM.

  4. #54
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    ...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.

  5. #55
    Quote Originally Posted by Frank B View Post
    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

  6. #56
    Quote Originally Posted by Frank B View Post
    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

  7. #57
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    @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.

  8. #58
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    > 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.

  9. #59
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    Quote Originally Posted by jonr View Post
    > 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.
    As long as the temperature does not change too much..

  10. #60
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    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?

  11. #61
    correct, but i have gone in close on the scope and messed with the numbers till I cant see any more movements

  12. #62
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    @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 by Frank B; 11-27-2020 at 11:30 PM.

  13. #63
    Quote Originally Posted by Frank B View Post

    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.

  14. #64
    FYI, (back to me lol), I got the clock speed thing working so ... thanks...

  15. #65
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,065
    Perfect

  16. #66
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    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).

  17. #67
    Senior Member
    Join Date
    Aug 2013
    Location
    Gothenburg, Sweden
    Posts
    336
    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.

  18. #68
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    I could see a use for an AUDIO_SAMPLE_RATE_NOMINAL that would always be 44100, 48000 or etc.

  19. #69
    Senior Member
    Join Date
    Aug 2013
    Location
    Gothenburg, Sweden
    Posts
    336
    What would AUDIO_SAMPLE_RATE_EXACT be then, given that clocks and PPL's are drifting and trimmed, their exact values unknown ?

  20. #70
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    723
    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.

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

Posting Permissions

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