opus - Feb 2018 - opus 1.2.1 regression with --enable-float-approx and --0fast

On Thu, Feb 22, 2018 at 8:34 PM, Jean-Marc Valin <jmvalin at jmvalin.ca>
wrote:
> Hi Stepan,
>
> I would need more information to be able to investigate further. It's
> legal for the decoder to output -32768, so it would be good if you could
> explain how this is unexpected.

Its unexpected because the decoder continues to output all samples of -32768
even when the microphone input is silence or near silence, so I would
expect the decoded values to be at or near 0.

> Ideally an audio file with details on
> how to reproduce the problem would help.
>
I will try to reproduce with opus_demo or opus-tools.

>
> Optionally, if you could bisect the git repo to see where the problem
> started.
>
> Cheers,
>
>         Jean-Marc
>
> On 02/22/2018 07:15 PM, Stepan Salenikovich wrote:
> > Hi,
> > I work on a webRTC application and recently tried updating from opus
> > 1.1.5 to 1.2.1
> >
> > Afterwards I noticed occasionally weird audio glitches. I finally
> > tracked down the issue to the opus decoder in my application
outputting
> > samples with the value of -32768.
> >
> > This behaviour stopped when reverting to opus 1.1.5 or compiling opus
> > 1.2.1 without configuring --enable-float-aprox and --0fast.
> >
> > The setup is a microphone as audio input into chrome v64 which then
> > sends opus encoded audio to my application and my application decoding
> > this audio stream.
> >
> > I could induce the glitches by breathing/blowing really loudly into
the
> > microphone. I noticed that occasionally this would result in the opus
> > decoder in my application to keep outputting a stream of -32768 (even
if
> > I stopped) until I talked normally for a bit.
> >
> > Is it possible that a regression was introduced between 1.1.5 and
1.2.1
> > when configuring with --enable-float-approx and compiling with
--0fast?
> >
> > Thanks,
> > -stepan
> >
> >
> > _______________________________________________
> > 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/20180222/489997a9/attachment.html>

On 02/22/2018 09:34 PM, Stepan Salenikovich wrote:
> Its unexpected because the decoder continues to output all samples
> of -32768 even when the microphone input is silence or near silence, so
> I would expect the decoded values to be at or near 0.
Oh, if the output is stuck at -32768, then it's likely some NaNs crept
in. The first thing to check is whether the problem is on the encoder
side or the decoder side (when if you use a 1.1 encoder with a 1.2
decoder and vice versa). In general, -Ofast is not IEEE-compliant when
it comes to NaN, so libopus has to work around that non-compliance.
> I will try to reproduce with opus_demo or opus-tools.
Thanks, that'll help a lot.

	Jean-Marc
> 
> 
>     Optionally, if you could bisect the git repo to see where the problem
>     started.
> 
>     Cheers,
> 
>             Jean-Marc
> 
>     On 02/22/2018 07:15 PM, Stepan Salenikovich wrote:
>     > Hi,
>     > I work on a webRTC application and recently tried updating from
opus
>     > 1.1.5 to 1.2.1
>     >
>     > Afterwards I noticed occasionally weird audio glitches. I finally
>     > tracked down the issue to the opus decoder in my application
>     outputting
>     > samples with the value of -32768.
>     >
>     > This behaviour stopped when reverting to opus 1.1.5 or compiling
opus
>     > 1.2.1 without configuring --enable-float-aprox and --0fast.
>     >
>     > The setup is a microphone as audio input into chrome v64 which
then
>     > sends opus encoded audio to my application and my application
decoding
>     > this audio stream.
>     >
>     > I could induce the glitches by breathing/blowing really loudly
>     into the
>     > microphone. I noticed that occasionally this would result in the
opus
>     > decoder in my application to keep outputting a stream of -32768
>     (even if
>     > I stopped) until I talked normally for a bit.
>     >
>     > Is it possible that a regression was introduced between 1.1.5 and
>     1.2.1
>     > when configuring with --enable-float-approx and compiling
>     with --0fast?
>     >
>     > Thanks,
>     > -stepan
>     >
>     >
>     > _______________________________________________
>     > opus mailing list
>     > opus at xiph.org <mailto:opus at xiph.org>
>     > http://lists.xiph.org/mailman/listinfo/opus
>     <http://lists.xiph.org/mailman/listinfo/opus>
>     >
> 
>

On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca>
wrote:
> On 02/22/2018 09:34 PM, Stepan Salenikovich wrote:
> > Its unexpected because the decoder continues to output all samples
> > of -32768 even when the microphone input is silence or near silence,
so
> > I would expect the decoded values to be at or near 0.
>
> Oh, if the output is stuck at -32768, then it's likely some NaNs crept
> in. The first thing to check is whether the problem is on the encoder
> side or the decoder side (when if you use a 1.1 encoder with a 1.2
> decoder and vice versa). In general, -Ofast is not IEEE-compliant when
> it comes to NaN, so libopus has to work around that non-compliance.
>
The encoder in my setup is always the one in chrome m64. I'm pretty sure
thats 1.2 and I'm not sure but I think they don't compile with -Ofast.
The decoder which gets stuck at -32768 is 1.2 with -Ofast. 1.1 with -Ofast
works, and 1.2 without -Ofast works as well.

> > I will try to reproduce with opus_demo or opus-tools.
>
> Thanks, that'll help a lot.
>
Having trouble right now compiling opus-tools against a local install of
opus 1.2 compiled with -Ofast... will ask on irc.

>
>         Jean-Marc
>
> >
> >
> >     Optionally, if you could bisect the git repo to see where the
problem
> >     started.
> >
> >     Cheers,
> >
> >             Jean-Marc
> >
> >     On 02/22/2018 07:15 PM, Stepan Salenikovich wrote:
> >     > Hi,
> >     > I work on a webRTC application and recently tried updating
from
> opus
> >     > 1.1.5 to 1.2.1
> >     >
> >     > Afterwards I noticed occasionally weird audio glitches. I
finally
> >     > tracked down the issue to the opus decoder in my application
> >     outputting
> >     > samples with the value of -32768.
> >     >
> >     > This behaviour stopped when reverting to opus 1.1.5 or
compiling
> opus
> >     > 1.2.1 without configuring --enable-float-aprox and --0fast.
> >     >
> >     > The setup is a microphone as audio input into chrome v64
which then
> >     > sends opus encoded audio to my application and my application
> decoding
> >     > this audio stream.
> >     >
> >     > I could induce the glitches by breathing/blowing really
loudly
> >     into the
> >     > microphone. I noticed that occasionally this would result in
the
> opus
> >     > decoder in my application to keep outputting a stream of
-32768
> >     (even if
> >     > I stopped) until I talked normally for a bit.
> >     >
> >     > Is it possible that a regression was introduced between 1.1.5
and
> >     1.2.1
> >     > when configuring with --enable-float-approx and compiling
> >     with --0fast?
> >     >
> >     > Thanks,
> >     > -stepan
> >     >
> >     >
> >     > _______________________________________________
> >     > opus mailing list
> >     > opus at xiph.org <mailto:opus at xiph.org>
> >     > http://lists.xiph.org/mailman/listinfo/opus
> >     <http://lists.xiph.org/mailman/listinfo/opus>
> >     >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20180222/db5b692a/attachment-0001.html>