NaN introduced with sample-exact fix in 1.0.91 #3685

zonkmachine · 2017-07-05T23:15:34Z

NaN in a project file from this comment in PR #3313 submitted by @Umcaruje
Edit: I edited down the original song to a minimal project.
issue3685.mmp.zip

The project goes silent just as the BitInvader sounds for the first time in bar 5.
<lmms-project version="1.0" creator="LMMS" creatorversion="1.0.0" type="song">
It was created with lmms 1.0.0 and the project breaks in lmms-1.0.91

If you turn the volume knob on the BitInvader track or if you render the project before you hit play the bug isn't triggered. I've been trying to spot something like an undefined variable in there but have come up with nothing so far.

The bug was introduced in 23433a7

23433a70b577bc67f2836c0ae98a4dc48ae40f93 is the first bad commit
commit 23433a70b577bc67f2836c0ae98a4dc48ae40f93
Author: Vesa <contact.diizy@nbl.fi>
Date:   Mon Jun 30 01:59:18 2014 +0300

    Sample-exact models: improve
    - Remove the redundant hasSampleExactData() function. Instead, signal lack of s.ex.data by returning a NULL in valueBuffer()
    - Cache s.ex.buffers and only update them once per period
    - Make valueBuffer() in AutomatableModel threadsafe so that it can be used for NPH's sharing the same model
    - Add sample-exactness to instrumenttrack's vol & pan knobs

The text was updated successfully, but these errors were encountered:

musikBear · 2017-07-06T12:33:25Z

There is more to this
Try this:

Open the FX-mixer.
Focus Master
rightclick and select 'remove unused channels'

Not only does the project sounds different, the issue with BitInvader is also gone. Somehow effects in unused channels are still influencing the playback. These channels are for presets thats no longer in the project !

issue3685_unusedChannelRemoved.zip

zonkmachine · 2017-07-06T13:24:19Z

I don't see this on my side. The project issue3685_unusedChannelRemoved.zip still has this issue on my setup. I can add that turning the volume down a bit and saving/reloading or turning normalization off on the BitInvader, also removes the glitch.

musikBear · 2017-07-07T10:23:47Z

@zonkmachine

issue3685_unusedChannelRemoved.zip still has this issue on my setup

Interesting! could be that selected backend is a factor, mine is SDL.
Otherwise the bug could be random, that would indeed be bad. I will make a 10 times repeat test with your orr. file, and the 'remove-channel' change.

musikBear · 2017-07-07T12:30:35Z

No it is not a backend thing. I found a peculiarity that explain why i have sound where you had non.
First, here are the combos

cuts sound
Lim+plate
Lim+HP
Lim+plate(W/D = 0
Lim+HP (W/D = 0
Lim+ plate OFF
Lim+ HP OFF
Lim (W/D = .67 +HP+Plate
Lim (W/D = .0 +HP+Plate

no sound cut
Lim OFF +HP+Plate
Lim +HP+Plate After one play with Lim OFF!

Its the last one
Lim +HP+Plate After one play with Lim OFF!
that leads to the confusing results
I can reproduce this outcome every time, so i am sure that this is correct.
So
IF you start by disabling (OFF in mixer ) the Calf-limiter, and let the BITINWADER play through once, then after that one play-through, you can re-invoke the Calf-limiter (ON in mixer), and now the whole track can be played, without sound-cut -Eg NaN will not occur.
However!
If you save the file in this 'play-through-state' it will not preserve this ability. The sound will again cut-off at next project-reload. Eg the state is not saveable.
My first erroneous result simply came from a play-through with sound..
I cant say i understand why we have that behaviour, but maby someone can..

zonkmachine · 2017-07-07T16:18:39Z

The actual NaN happens in the Limiter, yes... but that's not the issue. The limiter wasn't changed in the actual commit. Somewhere up-stream from the Limiter we are producing a value the limiter just can't handle very well and it goes bananas. It's the up-stream event I'm interested in here, not the limiter. The limiter has issues but I've failed to nail it down. It's an old package that isn't developed any more and probably our best bet there is to just wait for LV2 and the newer Calf packages to come true on LMMS.
However, the actual issue here more likely originates from our envelopes.

zonkmachine · 2017-07-07T19:05:34Z

@michaelgregorius I suspect this may be related to what you comment on here.

michaelgregorius · 2017-07-07T20:39:35Z

I have added the pull request #3687 to provide an option to debug floating point exception. Please refer to the pull request for more details.

michaelgregorius · 2017-07-07T20:41:37Z

@zonkmachine That might be the case. These exception really need to be weeded out.

This will check for infs/nans in between the effect units and will clear up most cases where projects with bad data would simply cut out all sound at one point or be all silent. It comes with a slight performance hit of some 2% more cycles. The down side is that now instead of cutting out at the point of bad data some large signals will get through that could potentially hurt equipment. Resolves: LMMS#1048, LMMS#3685

PhysSong · 2017-08-11T06:38:46Z

This behavior depends on too many arguments: playhead position before press play button, the wave shape in BitInvader, effects in the instrument, limiter's lookahead parameter, etc. So bisect may give wrong result for this.
Furthermore, if the bug was really introduced in 23433a7, it doesn't mean that commit is the direct cause of this bug.

There's nothing wrong with the input signal of the limiter in CH10, and its output contains a few number of(4~9 in my case) NaNs. In CH10, there are plate reverb and high pass filter. After these effects, the output signal becomes "the sea of NaN".
I tested it by FPE debugging and cross checked using manually inserted printf() so I think this result is reliable.

NaN is introduced here. If _peak has value 0, divide by 0 occurs.
I think it is a bug of calf limiter, not from LMMS core. With other limiter, there's no NaN anymore.

So I guess the bisect result is wrong and the real reason of this issue is a bug of calf limiter which occurs rarely.

musikBear · 2017-08-11T13:08:53Z

I think it is a bug of calf limiter, not from LMMS core. With other limiter, there's no NaN anymore.

@PhysSong -Good find! 👍

zonkmachine · 2017-10-16T13:49:12Z

Closing this as a duplicate of #3859.

zonkmachine · 2017-10-29T08:58:52Z

NaN is introduced here. If _peak has value 0, divide by 0 occurs.

@PhysSong Right. I hacked _peak above that line with: _peak = fmaxf( 0.0000001, _peak ); and that of course fixed the limiter right up. I think we should fix that for 1.2 . How about introducing an LMMS_MIN constant to use when you need a fmaxf or qMax( LMMS_MIN, Something ) to prevent 0? I've had use for it before and the FLT_MIN constants in float.h is a bit brutal. 1E-37 or smaller has no business in audio applications.

Edit: std::max is used in other places in audio_fx.cpp

zonkmachine · 2017-10-29T09:04:43Z

How about introducing an LMMS_MIN

Here: https://github.com/LMMS/lmms/blob/stable-1.2/include/lmms_constants.h#L51

zonkmachine · 2017-10-30T10:06:25Z

NaN is introduced here. If _peak has value 0, divide by 0 occurs.

I fixed that up as part of #3927

This will check for infs/nans in between the effect units and will clear up most cases where projects with bad data would simply cut out all sound at one point or be all silent. It comes with a slight performance hit of some 2% more cycles. The down side is that now instead of cutting out at the point of bad data some large signals will get through that could potentially hurt equipment. Resolves: LMMS#1048, LMMS#3685

zonkmachine added bug core labels Jul 5, 2017

zonkmachine mentioned this issue Jul 18, 2017

Allways remove infs/nans #3706

Merged

zonkmachine mentioned this issue Oct 5, 2017

Instrument 'on' glitch #3859

Closed

zonkmachine added the duplicate label Oct 16, 2017

zonkmachine closed this as completed Oct 16, 2017

zonkmachine mentioned this issue Oct 30, 2017

LADSPA - Fix various floating point errors #3927

Merged

zonkmachine mentioned this issue Nov 2, 2017

Fix wrong value interpolation #3929

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NaN introduced with sample-exact fix in 1.0.91 #3685

NaN introduced with sample-exact fix in 1.0.91 #3685

zonkmachine commented Jul 5, 2017 •

edited

Loading

musikBear commented Jul 6, 2017

zonkmachine commented Jul 6, 2017 •

edited

Loading

musikBear commented Jul 7, 2017

musikBear commented Jul 7, 2017

zonkmachine commented Jul 7, 2017

zonkmachine commented Jul 7, 2017

michaelgregorius commented Jul 7, 2017

michaelgregorius commented Jul 7, 2017

PhysSong commented Aug 11, 2017 •

edited

Loading

musikBear commented Aug 11, 2017

zonkmachine commented Oct 16, 2017

zonkmachine commented Oct 29, 2017 •

edited

Loading

zonkmachine commented Oct 29, 2017

zonkmachine commented Oct 30, 2017

NaN introduced with sample-exact fix in 1.0.91 #3685

NaN introduced with sample-exact fix in 1.0.91 #3685

Comments

zonkmachine commented Jul 5, 2017 • edited Loading

musikBear commented Jul 6, 2017

zonkmachine commented Jul 6, 2017 • edited Loading

musikBear commented Jul 7, 2017

musikBear commented Jul 7, 2017

zonkmachine commented Jul 7, 2017

zonkmachine commented Jul 7, 2017

michaelgregorius commented Jul 7, 2017

michaelgregorius commented Jul 7, 2017

PhysSong commented Aug 11, 2017 • edited Loading

musikBear commented Aug 11, 2017

zonkmachine commented Oct 16, 2017

zonkmachine commented Oct 29, 2017 • edited Loading

zonkmachine commented Oct 29, 2017

zonkmachine commented Oct 30, 2017

zonkmachine commented Jul 5, 2017 •

edited

Loading

zonkmachine commented Jul 6, 2017 •

edited

Loading

PhysSong commented Aug 11, 2017 •

edited

Loading

zonkmachine commented Oct 29, 2017 •

edited

Loading