From Steve's further e-mail:

> The bit that I'm concerned about is that the problem persists until 
> Audacity restarts (at least on my machine - Linux and XP)
> Why should _any_ Nyquist effect make a persistent change to Audacity's 
> behaviour?
> 
> I stumbled across this problem while working on a new plug-in, but it 
> can also be triggered by the included "lowpass filter" effect.
>  It is likely that other plug-ins could also trigger the problem.
> 
> Once this bug has been triggered, it does not only affect Nyquist 
> Generate plug-ins, but ALL GENERATORS AND EFFECTS and there is no way to 
> "undo" the problem. The only option is to save the project and restart 
> Audacity.
> 
> I totally agree that the problem is rather unlikely to occur (hence 
> no-one noticing it 'till now), but the affects are pretty extreme, so 
> like a P3 I don't think that it should be "ignored and left to mount 
> up". Hopefully since it has only appeared recently it will be relatively 
> easy for someone to locate.
> 
> I've submitted the bug http://bugzilla.audacityteam.org/show_bug.cgi?id=152
> 
> A bit more investigation indicates that any Nyquist function that uses 
> "biquad-m" is capable of producing the problem if the parameters are 
> such. This includes a lot of Nyquist plug-ins - basically any that use 
> filters. Should that information be included in Bugzilla, or can that 
> just be left to the developers?

I did try Effect > Low Pass without producing -1 samples. Have you got parameters for that effect that produce it? I was aware all generate effects were affected, but I can see now that Effect menu items are affected too. I also found the bug corrupts imported files, unless they are aliased.  

I can in fact reproduce this in 1.3.11, 1.3.8 and 1.3.3 Unicode Releases on Windows 7, so maybe you weren't using 16-bit in 1.3.11? It is not reproducible in 1.2.6, so we can give it the "R" flag.     

My rating of the bug depends how likely anyone is to find it, given it's taken at least three years for someone to do so. I certainly don't like the widespread effects we've both discovered, so it's now P4. To go higher I'd want a bit more persuading that built in Nyquist effects are likely to produce -1 samples. What parameters in built in Nyquist filter effects can produce this?

There are perhaps 2 bugs:

1) 
(lowpass8 s <frquency>) where frequency > half sample rate.
result = samples all at -1.0

IMO this should produce an error message.

This is not new - it's the same in Audacity 1.2. except that seems to produce samples at +1.0 unless frequency > sample rate, then it produces a shelf filter effect at a lower frequency.

If people agree that this is a bug, I'd say it is no more than a P5. I'm not actually sure that I'd class this as a bug at all as one should expect the result to be rubbish.

2) 
After applying the above effect, Generate and Effects processes all produce samples at -1.0. This continues until Audacity is restarted. This is the bug that I was referring to as bug id=152 and I agree that P4 is appropriate.

On Linux I can only reproduce this with Audacity 1.3.12 and later. For earlier versions, subsequent effects and generate functions work normally. I'll test this on XP shortly and report back.

(In reply to comment #2)

Test results from Audacity 1.3.11 beta on Windows XP:

Open Audacity (fresh install)
Edit > Preferences > Quality > Default Sample Format = 16 bit.
All other preferences at default values.

1) Generate > Noise > 1 second/0.8 amplitude/White
2) Effect > Nyquist Prompt
3) Enter the following code and click "OK"

(lowpass2 s 36000 2.5)

Effect returns all samples at -1.0

4) Generate > Tone > OK
All samples at -1.0


Test repeated on the following set-ups with the same results:
Audacity 1.3.12 beta on Windows XP:
Audacity 1.3.13-alpha-Apr 7 2010 on Linux (Ubuntu 9.04)
Audacity 1.3.11-alpha-Dec 29 2009 on Linux (Ubuntu 9.04)

I've found the reason why I was previously getting different results on Audacity 1.3.11 - I had "high quality > dither" set to "triangle.

Repeat the above test with 
Edit > Preferences > Quality > High Quality Conversion > Dither > Triangle.

Everything is the same up to and including step 3, but then:
4) Generate > Tone > OK
Tone generated correctly!

Steve wrote: 
> ... can be prevented from rearing its ugly head by adding the following line to > dispprisms.lsp
>
> 344   (defun nyq:biquad (x b0 b1 b2 a0 a1 a2)
> +345    (if (< a0 1.0)(error (format T "a0 < 1 in biquad~%"))
> 346     (let ((a0r (/ 1.0 a0)))

> This is not a fix, just a workaround, but it prevents the worst effects of the 
> bug.I suspect the main bug may be related to dither, but that's beyond me.
>
> Perhaps dispprisms.lsp should contain checking that filters do not attempt to 
> operate at frequencies above half the sample rate?

I suppose until someone can see a fix to this, we ought to throw an error like the above, but I can't get that code to work in either Win 7 or Ubuntu. It produces a generic "Nyquist did not return audio" for any lowpass input, including valid frequencies such as (lowpass8 s 400) on a 44100 Hz 16-bit PCM tone. The file I modified was \nyquist\dspprims.lsp. 

If a fix does not involve frequency checking in Nyquist, probably the rubbish output should be allowed. It seems better to fix by stopping rubbish in a track being placed in all new/modified tracks, in case there is some other case we haven't found (such as input from wrecked hardware).

(In reply to comment #5)

> It
>produces a generic "Nyquist did not return audio" for any lowpass input,
>including valid frequencies such as (lowpass8 s 400) on a 44100 Hz 16-bit PCM
>tone. The file I modified was \nyquist\dspprims.lsp. 

Sorry, my fault - there needs to also be an extra ")" at the end of line 348 to close the function.

That section from line 343 should be:

; convenient biquad: normalize a0, and use zero initial conditions.
(defun nyq:biquad (x b0 b1 b2 a0 a1 a2)
  (if (< a0 1.0)(error (format T "a0 < 1 in biquad~%"))
  (let ((a0r (/ 1.0 a0)))
    (snd-biquad x (* a0r b0) (* a0r b1) (* a0r b2) 
                             (* a0r a1) (* a0r a2) 0 0))))

The code will show an error if you use the "debug" button.
First line of debug output should read:
a0 < 1 in biquad


Although it only produces a general error message for users, it does give a meaningful debug message and prevents the more serious problem of corrupting new/modified tracks. 

I could modify dspprims.lsp so that will do proper frequency checking and output an error message, but I'm not sure what the policy is regarding making changes to the Nyquist code - I was under the impression that it was preferable not to modify it, but to make changes in the Audacity code when required. Also, as you say, I don't know if anything else could trigger the corruption problem.

I quite agree that the more important issue is stopping the rubbish being placed in all new/modified tracks, but I've no idea how to go about fixing that.

Created attachment 215 [details]
patch to error check nyq:byquad function in dspprims.lsp

patch to error check nyq:byquad function in dspprims.lsp

Sends error message to debug window if a0 is less than 1.0 rather than corrupting data. Error triggered by attempting to filter above Nyquist frequency or with negative frequency.

Does what it says, so over to Roger if he wants this error check to appear in Nyquist outside Audacity.

It looks to me like the problem is deeper, and we're just masking it with the check. It's on my list to look at, but meanwhile I think the suggested patch is a good idea. Thanks!

(In reply to comment #9)
added "patch_ready" keyword

(In reply to comment #3)
Since the original report refers to continuing problems, as does the title, and this was fixed with r11480 "Reset the filter every time to prevent one conversion affecting the next", this should be closed.
And Steve's patch has been applied to prevent the NaNs occurring (r11488).
And Michael put in r11470 (and r11460) to trap infs.

> patch has been applied to prevent the NaNs occurring (r11488)
So should be fine to set to "RESOLVED-FIXED". Done.

The patch breaks the eq-lowshelf function.

Run this in the Nyquist prompt and it throws the "a0 < 1 in biquad" error, though the code is valide and works in Audacity 1.3.14

(eq-lowshelf s 800 -15)

(In reply to comment #13)
> The patch breaks the eq-lowshelf function.
So what do you suggest? The current bug title "Nyquist function producing -1 samples corrupts all non-float audio until restart" is incorrect for the bug you have re-opened. Unless you can modify the patch so that it still fixes the subject issue, should the lowshelf issue be a new bug, depending on this one (suitably retitled)?

Created attachment 256 [details]
make error for invalid hz

I propose that the previous patch to dspprims.lsp is reverted because it breaks (eq-lowshelf).

That will reinstate the original problems of NANs when using highpass2, lowpass2, highpass4, lowpass4,.... (which appear as the "-1 samples" of the bug title).

As all of the functions known to cause this problem are based on either:
nyq:lowpass2
or
nyq:highpass2
they could be patched directly so as to throw an error if the "hz" parameter is out of range.

I've attached a patch to do this.

I'm not sure if I should have marked the old patch as obsolete. The new patch is written against revision 11739 so it is expecting that the old patch code is present (and removes it).

Bug title updated. 

I can confirm on Windows 7 that (lowpass8 s 22100) applied to a 44100 Hz track gives debug error output of "error: frequency out of range - 22100" so preventing -1 samples occurring. 

Valid code (eq-lowshelf s 800 -15) now runs the code instead of producing the debug error output "a0 < 1 in biquad".

(In reply to comment #16)
Any problems found with the new patch?
It looks good to go as far as I can tell.

Patch applied. Revision 11790.

Confirmed (lowpass8 s 22100) and  (lowpass2 s 22100) on a 44100 Hz track display error: "frequency out of range - 22100" in Debug window while (eq-lowshelf s 800 -15) runs the code. So RESOLVED - FIXED.