Bela

h1. Nerdy notes

This is just a collection of notes from/for developers. Sometimes it is also useful to know the mistakes that others made so not to waste your time when we already wasted ours. Note that if you attempt any of the hacks here it might void your warranty. Do not do this, please.

h2. Media clock on the Beaglebone Black with BeagleRT cape

The media clock is hardcoded to 44.1kHz. This can be changed by changing the PLL values in I2c_codec::startAudio.
Current settings are as follows

<pre>
writeRegister(0x02, 0x00) // Codec sample rate register: fs_ref / 1
writeRegister(0x03, 0x91) // PLL register A: PLL enabled, Q=2, P=1
writeRegister(0x04, 0x1C) // PLL register B: J= 7
writeRegister(0x05, 0x52) // PLL register C: D=5264, part 1
writeRegister(0x06, 0x40) // PLL register D: D=5264, part 2
</pre>

Notes:
For extensive reference check the TLV320AIC3104 Audio Codec reference manual http://www.ti.com/lit/ds/slas510d/slas510d.pdf, pages 45-46
Q is not relevant as PLL is disabled
J range is 1 to 63
D range is 0 to 9999
P range is 1 to 8
R range is 1 to 16
K=J.D=7.5264
P=1
R=1
PLLCLK_IN uses MCLK
CLKDIV_IN uses MCLK
PLLCLK is 12MHz
These values plugged in
f_{S(ref)} = (PLLCLK_IN × K × R)/(2048 × P)
will give 44100

The media clock can be changed setting different values for J and D. As it is currently structured, the PRU loop does not allow you to get much faster than 48000kHz (J.D=K=8.1920) as you will start getting underruns.

h3. Measure media clock drift with respect to As it turns out, on the CPU clock

On the BeagleRT cape the 12MHz clock is generated by the same master clock that drives the CPU, so these are going to be synced forever and ever (that is, do not expect any drift to occur between the media clock and the system clock).

h3. Measure media clock drift with respect to the CPU clock

As mentioned above, there is no such drift, as both clocks are driven by the same master clock.
To verify that Anyhow, this actually is the case, the follwing patch to PRU.cpp allows to log the time that takes for the PRU to get back to the ARM audio thread.
<pre>
static RTIME elapsedTime; // in nanoseconds
static RTIME startTime=0;
static long long int count=0;

while(pru_buffer_comm[PRU_CURRENT_BUFFER] == lastPRUBuffer && !gShouldStop) {
rt_task_sleep(sleepTime);
}
xenomai_gpio[GPIO_SETDATAOUT] = TEST_PIN_MASK;
elapsedTime=rt_timer_read();
xenomai_gpio[GPIO_CLEARDATAOUT] = TEST_PIN_MASK;
if(count==0){
rt_printf("values=[\n");
startTime=elapsedTime;
}
if((count&16383)==0 && count!=0){
elapsedTime=elapsedTime-startTime;
rt_printf("%llu\n", elapsedTime);
}
count++;
</pre>

Ideally it should be @elapsedTime==numAudioBufferSamples*16384.0/samplingRate*1e9 ±0.25*sleepTime@
assuming that @sleepTime==numAudioBufferSamples/SamplingRate/4.0@
Experimental results show that it is the case (see attached files clockanalysis.m , logovernightInPru.m, error.png)