Hi all, New to list and Opus Codec. I've been using it on a beagleboneblack with 'arecord'. One of the things I've noticed while encoding is that Opus reports a float with an 'x' along with "realtime". Where can I look up where this calculation is derived? It got me looking and I've noticed that when I record something from a known source (in testing) like an MP3 file, I can look at the resulting opus file and realize it doesn't match the original source over a long period of time. (or even the .WAV, which is how I back tracked to the .WAV and realized that might be a bit off topic for this list) The new recording is shorter than the original by significant amounts. So in trying to stretch it out (with SoX) to just play with it, that's when I noticed the number that's presented by 'opusenc' while recording and wondered how it knows that and of what it's representative. So, I'm going to crack into the docs -- but I thought I'd ask here in case anyone else has seen this phenomenon before. Thanks, -Ben -- ben at benjammin.net
On 2014-02-11 8:27 PM, Ben wrote:> New to list and Opus Codec.Welcome1> 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: https://git.xiph.org/?p=opus-tools.git;a=blob;f=src/opusenc.c;h=366893b7af325a67be90b33f991426a2c5665ef9;hb=HEAD#l1030> 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. -r
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. > > Welcome1 > >> 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: > https://git.xiph.org/?p=opus-tools.git;a=blob;f=src/opusenc.c;h=366893b7af325a67be90b33f991426a2c5665ef9;hb=HEAD#l1030 > >> 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. Cheers, -Ben