Multi-RX: Use current/max RX and TX sample rates for the equalizer.

[tmiw]

Looks like something that was missed when multi-RX was originally implemented. I think it helps but I'll include this PR in the next build to confirm.

[tmiw]

@drowe67, my understanding from emails Jose sent is that there is noise in the received audio unless the curves/volume levels in the filters are 0dB. This PR is to ensure that the filters use the same sample rates as what the various modes expect (e.g. possibly higher than 8K).

[tmiw]

@drowe67, this one is ready to merge.

[drowe67]

We have needed equaliser support for 2020 at Fs=16kHz for some time, so this PR is a step in the right direction well done 👍 I'm not sure what the current behaivour of the EQ is in 2020, probably the frequency scaling is wrong. I can't recall any strange noises.

I also can't recall any noises when the EQ is used in the 8 kHz modes. As we discussed recently, this feature has been around for a long time and has been in constant use.

1. Have you managed to repeat the problem this PR is designed to address?
2. How did you test this PR? Audio processing is hard to test, but I guess a basic test is the OP bug is gone, and no other audio is grossly distorted, and that the filter controls change the audio as expected.

Also I don't think this will work correctly in multi-rx mode, as I think designAnEQFilter is only called (1) when Start is pushed or (2) when the EQ controls are moved? Perhaps we need some sort of hook to call designAnEQFilter when the sample rate changes due to a Rx mode shift?

[drowe67]

Also on the graphs the X axis (freq) only goes out to 3000 Hz. Although it's probably no big deal, even in 16 kHz mode there is not much energy above 3000 Hz, and most of the EQ required is probably at the lower frequencies.

[tmiw]

@drowe67, unfortunately I couldn't duplicate it on my Mac but some of the Windows users were seeing it. This PR was merged into ms-optimization to get some runtime and I haven't heard anything about the noise still being there, FWIW.

Also I don't think this will work correctly in multi-rx mode, as I think designAnEQFilter is only called (1) when Start is pushed or (2) when the EQ controls are moved? Perhaps we need some sort of hook to call designAnEQFilter when the sample rate changes due to a Rx mode shift?

MainFrame::OnTimer() recreates the filters every 100ms using the below code:

    // Run time update of EQ filters -----------------------------------

    if (m_newMicInFilter || m_newSpkOutFilter) {
        g_mutexProtectingCallbackData.Lock();
        deleteEQFilters(g_rxUserdata);
        designEQFilters(g_rxUserdata);
        g_mutexProtectingCallbackData.Unlock();
        m_newMicInFilter = m_newSpkOutFilter = false;
    }
    g_rxUserdata->micInEQEnable = wxGetApp().m_MicInEQEnable;
    g_rxUserdata->spkOutEQEnable = wxGetApp().m_SpkOutEQEnable;

In fact, the audio from the running session changes in real time if you have the Filters window open and adjust the settings in there. 👍 Presumably the filters will readjust on RX mode changes with about 100ms lag.

[drowe67]

Hi @tmiw - I think the filters are only redesigned if the used tweaks the controls. This sets m_newMicInFilter, which triggers a single run time update. We wouldn't want the filters redesigned every 100ms, as that is unnecessary and would use quite a few cycles.

I think we also trigger new filter designs at start up as well.

[drowe67]

Another hint from a recent email from Jose:

In another order of comments ... identify that what produces the deformation of the reception audio in the latest MOONEER fdv 1.5.3, is the filter whose level should be 0 db ..
the problem is that to my liking there is a little low audio later in the reproduction .. but it is only personal opinion ..

I think he's suggesting this issue crept in with 1.5.3?

[tmiw]

Hi @tmiw - I think the filters are only redesigned if the used tweaks the controls. This sets m_newMicInFilter, which triggers a single run time update. We wouldn't want the filters redesigned every 100ms, as that is unnecessary and would use quite a few cycles.

I think we also trigger new filter designs at start up as well.

Oops, you're right. I just pushed a couple of commits to redo the filters on TX and RX mode changes.

I think he's suggesting this issue crept in with 1.5.3?

That's when multi-RX became official, so it would make sense that the issue started appearing when multi-RX did.

[drowe67]

Some more info on this one from a recent email from Jose:

In relation to the interference that arises when you use the analog mode .. only rx and tx are presented simultaneously in simultaneous all modes and with the volume in the filters above the flat level of 0 DB .. no before with the original software ...

Can we please get some more user feedback/test results from this one, along the lines that I mentioned a few days ago? While I can see this PR is heading in the right direction (e.g. proper EQ support for 2020, multi-rx issues), I would prefer not to merge until we are sure it has (i) fixed a bug/improved performance and (ii) is not causing any new problems.

Useful tests would be asking some one to run through all modes while trying the EQ in Tx and Rx, or popping up a test build for Jose and others to try. I'll take an action to try a few tests myself too.

[tmiw]

@drowe67, there was an older version of this PR in the builds I've been sending out (2aea293) and I hadn't heard anything so far. I'll merge the current state of this PR in and generate new builds, explicitly asking about the equalizer.

[tmiw]

@drowe67, I received further clarification from Jose LU5DKI. It sounds like this PR does resolve the analog buzzing/noise issue for him, FWIW.

[drowe67]

Hi @tmiw - I set up a full duplex sound card loopback and did some basic tests of the EQ functionality on this one:

1. Using 700C, tweaked all controls for mix and speaker and could hear the effect.
2. Same with 2020.

No odd sounds. I had multi-rx running but as it was synced up I guess it wasn't having much effect.

[tmiw]

@drowe67, I think it was originally showing up either with the Analog button pressed but with squelch off. I just tried it with the latter + band noise from my SDR program and I didn't hear anything weird either.

[tmiw]

@drowe67, I haven't heard anything indicating that this is still an issue (or that the most recent build caused another issue), so we can go ahead and merge.

[tmiw]

@drowe67, I just resolved conflicts so this should now be okay to merge. 👍