[opus] Question on opus_decoder output sampling rate

[Julien Chavanton]

Hi, another question on the same topic

Speex resampler at 44.1kHz seems to be very CPU intensive on Android (even
more than the Opus encoder)

While Speex at 48kHz is just fine.

I wonder any alternate solutions or ideas ?
Improve it, look for alternate solution ...

I am guessing the NEON optimization are still used for both, etc.


On Thu, Apr 2, 2015 at 4:46 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:

> The encoder and decoder can handle, 8, 12, 16, 24 and 48 kHz
> input/output. If doesn't matter what it gets encoded to/decoded from.
> you can initialize a decoder at 8 kHz and it'll still decode 48 kHz
> audio fine (you just won't get the high frequencies obviously). For
> sampling rates other than 8/12/16/24/48, then you'll have to do
> resampling. Have a look at the speexdsp resampler if you don't already
> have one.
>
> Cheers,
>
>         Jean-Marc
>
> On 02/04/15 10:42 AM, Julien Chavanton wrote:
> > Hi, is there any way to tell the decoder the output sampling Fz we want ?
> >
> > opus_decoder_create = Sampling rate of input signal (Hz)
> >
> > Considering this example (VoIP-out from WebRTC/RTP)
> >
> > MICROPHONE(44.1/48kHz) >> [encoder created at 48kHz but with
> > internalSampleRate set to 8kHz]>> INTERNET >> [decoder(created with
> > 48kHz)] >> 48kHz(?) >> G.711(8kHz)
> >
> > This leaves us with the only option to re-sample even if the internal
> > sample rate was set to 8kHz.
> >
> > This may not seem like a big problem since we could simply resample but
> > on a server with a lot of load this could be significant ?
> >
> > https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08
> > Is not very clear on these points.
> >
> > Regards
> > Julien
> >
> >
> > _______________________________________________
> > opus mailing list
> > opus at xiph.org
> > http://lists.xiph.org/mailman/listinfo/opus
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20160315/6e52de16/attachment.htm