Topic: Monitoring a microphone recording produces static only on Linux

[Ian @ un4seen]

Are you able to reproduce the problem yourself? If so, would it be possible to provide a minimal test (containing only the required code) to reproduce the problem and investigate what's happening?

[rileythefox]

Unfortunately I can't as I don't have a Linux machine and virtual machines aren't playing nicely. The application I'm using to test right now pretty much has the minimal amount of code needed to reproduce it but its written in C#. I can try to rewrite it in C but I had trouble linking against BASS when using Windows Subsystem for Linux because I'm not familiar with it.

[Ian @ un4seen]

I think a C# test should be fine.

[rileythefox]

Took a little while as I've been a bit busy but I've put the minimal amount of code needed to get the problem in a new project (just stripped away any error checking from my other test application). All the logic itself is identical so should reproduce the problem.

I've attached a C# source file in a zip file and its using ManagedBass for the API.

[Ian @ un4seen]

It took a while (MonoDevelop, which is what I'm using on Linux, had some complaints), but it's compiling and running now, but the problem doesn't seem to be happening. I can hear the reverb in the monitorHandle stream and then once the input goes silent so does the stream (after the reverb tail), and it stays silent. How long after silence begins should the static noise problem happen? And are you sure the problem is happening with this code? One reason I ask is that the BASS.ChannelSetFX call was failing until I added a "BassFX.Version" call before it (to get the BASS_FX library loaded). Perhaps too much of the original code was removed?

You mentioned being unable to test on Linux yourself due to Linux VM troubles, but perhaps you could use a bootable USB stick instead? I think most Linux distros will let you run from a USB stick without first installing.

[rileythefox]

Hi. I couldn't get Linux to co-operate with me (probably just my fault) but I re-sent the application to someone who is helping me test and modified it until the problem came back. It does appear I removed a little too much beforehand but I have now basically confirmed exactly where the pain point is.

I've attached the updated code for the minimal test (it calls BassFx.Version now so BASS_FX should load correctly) and confirmed as of 10 minutes ago with one of the users who tested it when writing this that this exact code caused the problem. The most important change is to the ProcessRecordData function. I have added back the call to BASS_ChannelGetData and that immediately caused the problem. I ensured that the DSP functions for the Gain is correctly receiving floating point data that it expects before doing this so that is entirely ruled out.

Hope this will finally get close to finding out what the cause is.

[Ian @ un4seen]

Ah! I see what it is now. BASS_FX's freeverb effect has a bug with mono data (there's an uninitialized value resulting in occasional NaNs). Here's an update with a fix for that:

   www.un4seen.com/stuff/bass_fx-linux.zip

[rileythefox]

Hi, I tried the update and was told the problem was worse than it has ever been up until this point. This was tested using the same code I attached in the previous post.

[Ian @ un4seen]

That's strange. Is the updated libbass_fx.so library definitely being loaded? BASS_FX_GetVersion should return 0x02040c0c (2.4.12.12).

One change I had to make to the code was to remove the FXSetParamters call because MonoDevelop doesn't like how "reverbParameters" is defined, so the effect is using default parameters. That shouldn't make a difference to the problem, but you could try leaving the defaults too and see if you/tester still has the problem then.

[rileythefox]

I set the Freeverb parameters to default and I was told it still has the problem. I have attached a sample mp3 file of what the monitoring sounded like.

In the post you gave the update, you mentioned an uninitialised value that resulted in NaNs. Isn't the data being passed to the Freeverb effect in 16 bit? NaN values would be for floating point data right? And there's no problem when using BASS_SAMPLE_FORMAT on the channels so it seems like just an issue with 16 bit?

Did you try to remove the BASS_ChannelGetData call in the code I provided and see if the problem went away like I've observed? Still unsure as to how that call can affect the monitoring channel's data.

[Ian @ un4seen]

The freeverb effect's uninitialised value was in the stack, so it would have whatever value happened to be left in that memory by previous code (hence the result can change when changing the previous code). The value gets multiplied by 0 (if the fWidth parameter is left at 1), so the uninitialised value wouldn't make any difference a lot of the time, but if it happens to be a NaN then it'll still be so after being multiplied by 0 and that ends up in the output.

I'm not seeing any problems here after the BASS_FX update. Your latest recording looks like it could be a different issue, possibly buffer underruns. I notice you're setting the device period to 5ms and device buffer to 10ms. It may be that those are too low for some systems. Does the problem still happen with those left at defaults? Please also try setting a WAV writer on the stream and see if the problem is present in that (like before).

[rileythefox]

Hi, so I reset the update period and device buffer length by commenting out the lines that changed them but the problem still persists in both the realtime monitoring stream and the outputted wav file. Oddly enough however the static sounds are only heard when listening in certain applications.

I opened the file in VLC, there are no static sounds. Then I opened the file in audacity and the problem can be heard. This is a file that was outputted by a Linux system and the problem can be heard in it on both Windows/Linux - but only in some applications?

Here's a screenshot of the waveform and spectogram of the file in audacity.

[Ian @ un4seen]

Please upload the WAV file (written by BASS_Encode_Start from the monitoring stream) to confirm whether the problem is still NaNs or something else.

[rileythefox]

I've attached the wav file in a zip.

[Ian @ un4seen]

That does look like it's still the same problem as before. Is it definitely using the updated libbass_fx.so file, ie. BASS_FX_GetVersion confirms it? Please also confirm that the test code is the same as you posted minus the "Bass.FXSetParameters" call, or have you made any other changes?

[rileythefox]

The BASS_FX version is indeed the latest one you provided. The test code is the same minus the following things:

- The Bass.FXSetParameters call
- Bass.UpdatePeriod call
- Bass.DeviceBufferLength call

The last 2 I just commented out to put them back to the defaults after you suggested putting them back to the default values.

The only other difference in the test code is the addition of BASS_Encode_Start to write the monitoring stream to a wav file.

[Ian @ un4seen]

Ah, I think I see what the problem is. Here's another update for you to try:

   www.un4seen.com/stuff/bass_fx-linux.zip

Let me know if it's still happening with that.

[rileythefox]

This seems to have fixed the issue! I'll get a few other people to confirm just to make sure, as well as reverting some of the code back to what it should be (update period, FX parameters etc) and then I will report back whether it is completely fixed. What was the problem identified this time?

[Ian @ un4seen]

Good to hear it's finally sorted. The previous update had a bug that meant it didn't actually totally prevent the NaNs (just changed/moved them a bit).