Search results

Hello, and thanks for the reply! I looked up teensy-ntp (and the thread in which Dan introduces that project); I'm certain that I'll be able to learn a lot from it, particularly the PID implementation (to date I've just been using a buffer-fill-level/delay-locked-loop algorithm for low-accuracy...

(First, if this isn't the appropriate category in which to post, please feel free to relocate this thread!) I've posted previously about my networked/distributed audio experiments, and I'm looking again at synchronising audio across a network of Teensy 4.1s as best I can. I know I can start...

Thanks for giving this a try! Perusing your changes is an eye-opener in itself. That's the approach I've taken so far. The aim is to support distributed spatial audio, so perfect synchronisation is the dream. For now, just something that works, while I build up an understanding of the workings...

I'm very much open to suggestions and ideas. Your previous post has given me plenty of things to investigate (e.g. how AudioInputSPDIF3, AudioOutputI2S, etc. attach an ISR to a DMAChannel... I guess this is the basis for the system of interrupts on Teensy). Thank you for taking the time to share...

I cannot exclude that possibility. Thank you very much for the screenshot; that really clears things up. I wasn't taking account of SAI1_CLK_PRED and SAI1_CLK_PODF. So, as far as I understand, the output frequency of SAI1 should be (256 * MY_TARGET_FS).

Thank you very much for the replies! @Chris O. this is interesting stuff. I downloaded MCUXpresso Config Tools, and that (plus the i.MX RT1060 reference manual) has thrown a little more light on how clocks are set up. So the manual says PLL4's output frequency = Fref * (DIV_SELECT + NUM/DENOM)...

Hi all, I'm working on a networked audio project, and naturally I'm faced with issues of clock drift and jitter. To date I've been using a delay-locked loop approach (something akin to that described by Fons Adriensen here), but for improved inter-client synchronicity I'm keen to explore other...

Ah, thanks for the tip re. waitForLink()! Gist updated accordingly. As I mentioned above, it seems that after a while (and this while varies) top level loop() stops being called. Under such conditions, AudioSteam::update() continues to be called, however. I'm testing with two Teensy 4.1's and...

Thanks very much for following up on this, shawn. And apologies for not providing full code above -- I'll link to a gist at the bottom of this post. I'm juggling branches a bit at the moment, working on versions with NativeEthernet and QNEthernet in parallel, while also working on an app to send...

Thanks shawn. Is that under a new tag, or just on the main branch? There's every possibility that I'm doing something wrong, but so far QNEthernet is behaving quite unstably for me. In my JackTripClient::begin() method, I have: uint8_t JackTripClient::begin(uint16_t port) {...

Thank you very much for your reply, shawn. I was looking at making the switch to QNEthernet prior to posting, and the packet-buffering feature looks like it'll come in very handy. As you may have noticed, I've been using TeensyID to generate a MAC address; great that QNEthernet does the same...

Hello, I'm working on setting up multiple Teensy 4.1's as JackTrip clients for audio spatialisation (e.g. distributed WFS). Using NativeEthernet, I have a collection of ethernet-shield-equipped Teensies all receiving UDP packets of encoded audio from a JackTrip hub server running on a laptop...