audio clock slip

Status
Not open for further replies.

jonr

Well-known member
Just getting started with teensy audio. I imagine that the teensy 4 derives its i2s clock from something that isn't an exact multiple of 44100. So if I'm receiving real-time audio on a PC at 44100 sps and sending it to a teensy (via USB) and then from the teensy via i2s, I expect to soon see buffer over/under-run (perhaps losing or gaining 1.4 samples every second). Is it possible to adjust audio output rate to be nearly perfect? For example, tune the 600 Mhz system clock downward to 599.98 Mhz, which is about an even 13605x of the desired 44100? Or occasionally insert/delete samples to account for rate differences as buffer gain/depletion is detected?

Would also be useful if the system could use an external clock source for audio (as the pros do).
 
So if I'm receiving real-time audio on a PC at 44100 sps and sending it to a teensy (via USB) and then from the teensy via i2s, I expect to soon see buffer over/under-run (perhaps losing or gaining 1.4 samples every second).

We're using asynchronous rate feedback, where the USB host is supposed to automatically adjust the data rate to match Teensy's clock.


Is it possible to adjust audio output rate to be nearly perfect? For example, tune the 600 Mhz system clock downward to 599.98 Mhz, which is about an even 13605x of the desired 44100?

Yes, you can adjust it in very fine increments. But whether you need to stop the clock to do so is an open question...

On Teensy 4 the audio clock is generated by PLL4, which offers very fine grain control. I do not know if the PLL fractional mult/div settings can be changed while it's running. If you experiment, I'll be curious to hear how it goes.


Or occasionally insert/delete samples to account for rate differences as buffer gain/depletion is detected?

Again, we're using asynchronous rate feedback where the USB host is responsible for this sort of thing.

USB audio class 1.0 defines 3 modes. The adaptive mode puts the responsibility for matching rates on the device side. There is also a synchronous mode, where both sides perfectly match to the 1 kHz SOF packets.


Would also be useful if the system could use an external clock source for audio (as the pros do).

Yup, that would be a nice feature which would make some people very happy. That is the main reason I'm curious to hear whether PLL4 can be adjusted while running.
 
Regarding PLL4, it looks like it needs to be stopped and restarted to change. But there are periods when an audible glitch would be harmless. For example, on startup. Ie, run for a few minutes to get a GPS fix, adjust the PLL for best accuracy, then stop adjusting it and start the audio session.

An alternative to changing PLL4 might be tweaking the 24 mhz clock it is derived from. I wonder if the internal RC 24 Mhz oscillator could, with GPS or NTP discipline become more accurate than the crystal oscillator? Then switch to it?
 
Interesting idea on the RC oscillator. Usually they are far less stable and much more temperature sensitive than crystals, but maybe that could be compensated somehow if you have access to reliable GPS time?
 
Another option would be to flip between PLL4 and PLL5. I don't know if that would cause any audible glitch.

It does appear that when the crystal is exactly 24 mhz, the system will produce exactly 44100 sps i2s audio. Ie, quite good for must applications.
 
Even if NXP's documentation says you have to stop PLL4, might be worthwhile to do a quick check to just see what happens if you make small changes to the settings while it's running.

But again, as far as USB audio is concerned, the USB audio class specification gives 3 ways to deal with the need for differing clock speeds between host & device. Teensy's USB audio (device mode) is using the asynchronous method, where a dedicated isochronous endpoint continuously transmits feedback to the host. In asynchronous mode, the host is responsible for adjusting the data rate to match the device's requirement.
 
> the host is responsible for adjusting the data rate to match the device's requirement

Understood, and helpful to know this. But if the data is coming into the PC from some other source (eg, network), it can be fairly difficult for the PC host to adjust the rate (say from 44100.01 to the 44100.00 the teensy wants to receive).
 
Despite being fairly difficult, at least some method to adjust the data rate in real time is built into the USB audio drivers on all systems. The USB spec doesn't require or recommend any particular algorithm, only that the host must do it. Whether it's difficult is really a matter of opinion. We have sample rate conversion code in the audio library now, contributed by Alex Walch as part of the S/PDIF input. Future Teensy boards will have dedicated hardware which does asynchronous sample rate conversion which NXP claims has errors lower than -120 dB (and on those boards we may switch to adaptive mode and implement USB host audio). I really do not believe this sort of sample rate conversion is much of an issue for modern PC hardware.

To keep these numbers is perspective, a 0.01 change on 44100 Hz is 0.226 ppm. Most PCs use an ordinary crystal oscillator, similar to Teensy, where crystals typically have an initial accuracy spec in the 20 to 50 ppm range. Even temperature compensated crystals tend to be in the 1 to 2 ppm error range. Getting down into that 0.226 ppm accuracy range usually involves an oven controlled crystal. The odds of any two digital audio systems without a shared clock being that close to each other are pretty slim. Most gear uses ordinary crystals which are typically ~30 ppm accurate.
 

I'm not sure if this datasheet describes recent model, but be aware that they had a design flaw such that they lost vacuum when stored over 30 dec C.
I only can see an advantage if Teensy can run off 10 Mhz, or, in case of audio, bitclock is exactly or sub-multiple of 10 MHz. Any PLL will introduce phase jitter.
(I played with one some time ago, but gave up on it)
 
I'm no expert, but I see these choices for audio rate sync where there is a teensy and other audio clocks:

a) Use a shared clock source. Certainly possible if the teensy is the clock source, not clear if it isn't.

b) Resample to match rates with some algorithm to discover the rate difference

c) Match clocks well enough.

"Well enough" depends: say 44100 sps, 24 hour session, 1K samples of buffering. With < .26 ppm error, it works and > .26 ppm it doesn't. My understanding is that this is easy to achieve with GPS discipline. Or, in some cases (shorter sessions?), NTP discipline?

Perhaps b) is such low impact that a) and c) aren't worth the trouble?
 
NTP works better than I guessed. I run chrony on my PC and it reports that the system clock wanders around 5 ppm fast but is corrected to .01 ppm.

My sound card's rate is a bit off - I have to slow the PC by 10 ppm to avoid glitches.
 
Indeed oven controlled atomic clocks are incredible for audio, it makes a world of a difference, but you have to hear it in person to really experience the difference. They are expensive, but for serious work it’s almost negligible if you want your audio to sound as best as it can. We finally upgraded our clocks to one of the best on the market with a claimed stability of <+/-0.02 PPM. So it would be nice to integrate it’s 10Mhz clock with the Teensy when I finally decide to finish one of the projects I have in mind.
 
There is frequency accuracy and jitter. Hopefully nobody is thinking that something like a 10 ppm difference in frequency is audible (unless it causes a buffer under-run). Jitter does effect sound - would be interesting to see a jitter spec (RMS ps of period) for the teensy clock.
 
Status
Not open for further replies.
Back
Top