[opus] Help with OpusEnc (SOLVED - sort of)
ben at benjammin.net
Tue Feb 18 12:23:14 PST 2014
On 2014-02-12 12:11 PM, Ralph Giles wrote:
> On 2014-02-11 8:27 PM, Ben wrote:
>> New to list and Opus Codec.
>> One of the things I've noticed while encoding is that Opus reports a float with an 'x' along with "realtime".
> This is intended to measure the cpu performance of the encoder. The
> float is the number of seconds of audio data processed divided by the
> number of real-time seconds since encoding began.
> If openenc displays '1x realtime' then the encoder is only just keeping
> up with the input data from arecord. If it displays '524x realtime' then
> it would need only .5% cpu to keep up with a live stream.
>> Where can I look up where this calculation is derived?
> The value is computed here:
>> The new recording is shorter than the original by significant amounts.
> Shorter as in data is missing, or that the playback length doesn't
> exactly match the walltime while you were recording? This could be a
> couple of different things.
Found the source of the problem to this post.
It turns out the TI TLV320AIC3106 (and possibly variants) REALLY wants the PLL registers ALL set.
Currently, the tlv320aic3x.c driver writes out all needed registers, but somehow registers matching default values aren't re-written.
I'm not sure where, (ALSA?) issues a chip software reset and then only programs the needed registers skipping one of the 2 registers for the PLL that generates the sampling clock.
This results in the PLL generating a 1.5MHz BCLK/46.875KHz frame clock and not the desired 1.536MHz/48KHz clocks.
So the resulting audio stream is short in samples over time every second.
Now I just need to determine why/where the layer that's not writing BOTH PLL_D registers and fix it. Yay.
But I thought I'd let you guys know this bug exists -- not related to OPUS, but in the TI ARM architecture when coupled to their TLV320 codec.
More information about the opus