opus - Jun 2013 - running at 44.1K but with standard frame sizes

Hi all,

I'm implementing the opus codec for a proprietary RF link (for fullband
audio) and want to make sure I understand something.
The link is currently running at 44.1KHz - realtime (i.e. streaming from an A/D
at one side, ultimately to a D/A at the other).
Rather than muck with all the infrastructure, I'm looking at how to run Opus
at 44.1K.
I have flexibility in the frame sizes of the unencoded audio, and packet sizes
on the RF link.

So, I was digging through the code, and I didn't see any attempt to measure
in realtime the actual audio rate (makes sense, since this codec can work
offline too).

Opus_custom seems to be needed if you have a certain frame size constraint with
low latency.  I don't have that.  I can use the stock frame sizes ( 120,
240, 480, 960, 1920, and 2880 sample/frame).

My conclusion is that I could set up Opus for 48K (stereo), and in reality run
it at 44.1K, as long as I use stock frame sizes, and it would be fine.

The only issue I can think of is any of the perceptual stuff will be off by -8%,
e.g. crossover/mask frequencies, etc.  Or is that true?
And with Opus_custom is all that stuff recalculated?

If I do need to go to opus_custom, it seems that it's still best to use the
stock frame sizes, true?

Thanks!

Marc

> I'm looking at how to run Opus at 44.1K. I have flexibility in the
> frame sizes of the unencoded audio, and packet sizes on the RF link.
You should probably consider resampling. It's not that expensive and it
would make things easy. But otherwise, see below.

On 06/14/2013 06:23 PM, Marc Lindahl wrote:
> So, I was digging through the code, and I didn't see any attempt to 
> measure in realtime the actual audio rate (makes sense, since this 
> codec can work offline too).
What do you mean by "measure in realtime the actual audio rate"?
> Opus_custom seems to be needed if you have a certain frame size 
> constraint with low latency.  I don't have that.  I can use the
> stock frame sizes ( 120, 240, 480, 960, 1920, and 2880
> sample/frame).
> 
> My conclusion is that I could set up Opus for 48K (stereo), and in 
> reality run it at 44.1K, as long as I use stock frame sizes, and it 
> would be fine.
Do not do that, ever. Everything is calibrated for 48 kHz and you will
likely cause audible noise. Besides, running at the wrong rates means
you lose all compatibility anyway, so you might as well use the custom
modes. Using custom modes means you would probably want to choose a
frame size that's a power of two and save a few extra cycles (maybe even
reuse a platform-specific power-of-two FFT).
> The only issue I can think of is any of the perceptual stuff will be 
> off by -8%, e.g. crossover/mask frequencies, etc.  Or is that true? 
> And with Opus_custom is all that stuff recalculated?
Yes, custom modes properly adjust all the psychoacoustics to the exact
sampling rate.
> If I do need to go to opus_custom, it seems that it's still best to 
> use the stock frame sizes, true?
There is no "stock frame size" with Opus custom. Modes are generated
on
the fly (or you can always pre-generate them) with any frame size. The
frame size is that it can't have prime factors above 5, but that's about
the only constraint.

Cheers,

	Jean-Marc

Hi Jean-Marc,

On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote:
>> I'm looking at how to run Opus at 44.1K. I have flexibility in the
>> frame sizes of the unencoded audio, and packet sizes on the RF link.
> 
> You should probably consider resampling. It's not that expensive and it
> would make things easy. But otherwise, see below.
Yes, considering your and Ben's remarks, I'm considering this.  I saw
the 'tools is using the speex resampler, I'll look at it.
> 
> On 06/14/2013 06:23 PM, Marc Lindahl wrote:
>> So, I was digging through the code, and I didn't see any attempt to
>> measure in realtime the actual audio rate (makes sense, since this 
>> codec can work offline too).
> 
> What do you mean by "measure in realtime the actual audio rate"?
Meaning using the CPU clock via time() to calculate the realtime data rate. 
Nevermind, it's a red herring.
> 
>> Opus_custom seems to be needed if you have a certain frame size 
>> constraint with low latency.  I don't have that.  I can use the
>> stock frame sizes ( 120, 240, 480, 960, 1920, and 2880
>> sample/frame).
>> 
>> My conclusion is that I could set up Opus for 48K (stereo), and in 
>> reality run it at 44.1K, as long as I use stock frame sizes, and it 
>> would be fine.
> 
> Do not do that, ever. Everything is calibrated for 48 kHz and you will
> likely cause audible noise.
How would it cause audible noise, I don't understand that part?  After all
the frequency calculations are off by 8%, that's not too extreme...
> Besides, running at the wrong rates means
> you lose all compatibility anyway, so you might as well use the custom
> modes.
Except, based on Ben's previous comments, possibly the quality isn't as
good?
> Using custom modes means you would probably want to choose a
> frame size that's a power of two and save a few extra cycles (maybe
even
> reuse a platform-specific power-of-two FFT).
That's interesting? there isn't anything in the compression (estimators,
etc.) or FEC that really 'likes' multiples of 120 samples?
> 
>> The only issue I can think of is any of the perceptual stuff will be 
>> off by -8%, e.g. crossover/mask frequencies, etc.  Or is that true? 
>> And with Opus_custom is all that stuff recalculated?
> 
> Yes, custom modes properly adjust all the psychoacoustics to the exact
> sampling rate.
Got it.
> 
>> If I do need to go to opus_custom, it seems that it's still best to
>> use the stock frame sizes, true?
> 
> There is no "stock frame size" with Opus custom. Modes are
generated on
> the fly (or you can always pre-generate them) with any frame size. The
> frame size is that it can't have prime factors above 5, but that's
about
> the only constraint.
What I meant was, 120, 240, 480, 960, 1920, or 2880 samples, the sizes imposed
in the normal mode.

So I still wonder, if you set up a custom mode, but then had all the settings
the same as a normal mode, would the codec perform worse, or the same?

Thanks for your thoughtful replies.

Best,
Marc