Library: AudioTiming

Status
Not open for further replies.

Frank B

Senior Member
https://github.com/FrankBoesing/AudioTiming

I'm about to write a library that will allow you to influence the internal timing of the Teensy audio library.
The audio library runs at 44117Hz, not 44100. This is because the timers for the ADCs, DACs and PWM cannot be set to 44100Hz accurately enough.

As a first step, (development is still "in progress") the AudioTiming library allows to operate the timer for the ADCs and DACs pin-triggered. (PWM follows soon)

i.e. you can synchronize the mentioned IN- and Outputs with a frequency which is applied to a PIN of the Teensy. It does not matter if the Teensy generates this frequency itself or an external generator generates it.

Why this library?
- USB sound works better with exactly 44100 Hz
- ADAT requires 44100 Hz
- SPDIF works better with 44100Hz
...
- If the above objects are not used, the sample rate can now be flexible.



Hint: Fortunately, the I2S protocol used by many audio-library objects uses a so-called "framesync". This sync toggles a pin (Pin23 default) with the sample rate.
The timer for I2S is also sufficient to operate at exactly 44100 Hz.

Ideas:
- If no I2s is used, why not add a "dummy" I2S - just as frequency-generator for the lib? The FrameSync-Pin can be on the Teensy-Backside, where it less annoying if not used.
- external i2s masters can control the Audio library

@Paul - maybe some code from this library can be integrated directly into the AudioLibrary.
 
Last edited:
Usage:
Code:
#include <AudioTiming.h>

...
...

AudioTiming audiotiming;

void setup() {

  audiotiming.init();
  audiotiming.usePin(23); //I2S Framesync-Pin or any other digital pin.
  audiotiming.begin();

  AudioMemory(...);

- more is planned
 
What kind of issues arise with USB due the non-ideal sample rate? How do they manifest in the sound? I've tried USB before and had some fidelity issues but never delved to deep into why.
 
While this +17Hz thing should be basically a non-issue since it is still within the digital audio white book specified tolerance, reality is different. Some real world USB audio input drivers, mostly seen in the Linux and there especially the Raspberry world, would not be able to deal well with that, either producing clicks, dropping frames or push the ERC to its limits, thus degrading the audio quality.
 
In the past, there was also a problem with apple macs, if I remember correctly.
Apart from USB, ADAT and S/PDIF and fixed 44100Hz (there was at least one user who had problems with his S/PDIF equipment - 17 Hz are close to the allowed tolerance limit), other frequencies are interesting, too. For me, for example MP3 with 48kHz samplerate + other in- or outputs. Or using the I2S as a slave, with clock from a master, together with the inbuilt DACs or ADCs.
 
I've added three functions:

- double readI2S_freq(): returns the current I2S sample rate.
- bool setI2S_freq(float fsamp): sets the I2S sample rate.
- void fakeI2S(void): starts a "fake" I2S which can be used to generate the sample rate, if no real I2S is used in the program.
(Set the desired samplerate and the pin afterwards. Default values: 44117Hz, no pin)
 
Last edited:
Still not understanding why you go through pin interrupts instead of using directly the I2S frame interrupt or DMA trigger to fully replace the PDB.
 
I stand corrected. Apparently, there is no frame sync trigger. There is only a word start interrupt trigger which would require some code logic to drop itself every second time to be used for frame sync.
 
Status
Not open for further replies.
Back
Top