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

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>

Any luck reproducing the problem with opus_demo or opus-tools?

	Jean-Marc

On 02/22/2018 10:14 PM, Stepan Salenikovich wrote:
> 
> 
> On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca
> <mailto: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>
<mailto:opus at xiph.org
>     <mailto:opus at xiph.org>>
>     >     > http://lists.xiph.org/mailman/listinfo/opus
>     <http://lists.xiph.org/mailman/listinfo/opus>
>     >     <http://lists.xiph.org/mailman/listinfo/opus
>     <http://lists.xiph.org/mailman/listinfo/opus>>
>     >     >
>     >
>     >
> 
>

On Fri, Mar 2, 2018 at 3:34 PM, Jean-Marc Valin <jmvalin at jmvalin.ca>
wrote:
> Any luck reproducing the problem with opus_demo or opus-tools?
>
No, I wasn't able to with opus-tools so far. My next plan is to git-bisect.

>
>         Jean-Marc
>
> On 02/22/2018 10:14 PM, Stepan Salenikovich wrote:
> >
> >
> > On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at
jmvalin.ca
> > <mailto: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>
<mailto:opus at xiph.org
> >     <mailto:opus at xiph.org>>
> >     >     > http://lists.xiph.org/mailman/listinfo/opus
> >     <http://lists.xiph.org/mailman/listinfo/opus>
> >     >     <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/20180302/34caa939/attachment.html>