Dump feature vectors

[drowe67]

Proposal for a freedv-gui test mode/feature to dump a file of features_out.f32 vectors (36 cols each, x length of sample). These are the vectors at the output of the RADE decoder, that are fed to the FARGAN vocoder for synthesis. By comparing them to a corresponding input set of features_in.f32 vectors, we can objectively measure distortion (using radae/loss.py) of the RADE signal as it passes through freedv-gui.

The features_out.f32 file should start when sync is obtained, and stop when sync stops.

Use cases include:

1. Testing the implementation of RADE Rx on freedv-gui, ensuring there is no additional distortion introduced into the RADE signal from its path through freedv-gui. In this case we would use a known-good Tx, that takes features_in.f32 and creates a tx wave file that is fed to a freedv-gui Rx.
2. Testing the implementation of RADE Tx on freedv-gui, by taking a known input speech wavefile, and using it to create a tx wave file. A known good RADE receiver could then be used to test the quality of the Tx waveform, compared to a reference implementation.
3. OTA optimisation. For example play a known speech source file (which has a corresponding features_in.f32), and measure the loss under various channel and radio settings (ie AGC, Tx drive, or additional filtering).
4. Test the effect of end user input speech processing, microphones, on RADE performance. If you filter the input, or insert noise suppression, or use a different headset, what is the effect on the RADE loss metric?

[tmiw]

Is this something that would be usable via of the unit test infrastructure being worked on in #761? Or is this intended to be usable during normal usage of FreeDV?

EDIT: I guess for (4) it would have to be usable during regular operation. That brings up the question of how the files get generated (i.e. is a new file created every time PTT is toggled, we keep appending to a single set of files, etc).

[drowe67]

Initially for unit testing, but I can see some possibilities for OTA tuning/debugging.

[tmiw]

Any remaining items needed here, or can this be closed? We're able to capture both RX and TX features now:

    parser.AddOption("f", "config", "Use different configuration file instead of the default.");
    parser.AddOption("ut", "unit_test", "Execute FreeDV in unit test mode.");
    parser.AddOption("utmode", wxEmptyString, "Switch FreeDV to the given mode before UT execution.");
    parser.AddOption("rxfile", wxEmptyString, "In UT mode, pipes given WAV file through receive pipeline.");
    parser.AddOption("txfile", wxEmptyString, "In UT mode, pipes given WAV file through transmit pipeline.");
    parser.AddOption("rxfeaturefile", wxEmptyString, "Capture RX features from RADE decoder into the provided file.");
    parser.AddOption("txfeaturefile", wxEmptyString, "Capture TX features from FARGAN encoder into the provided file.");
    parser.AddOption("txtime", "60", "In UT mode, the amount of time to transmit (default 60 seconds)", wxCMD_LINE_VAL_NUMBER);

[drowe67]

Thanks @tmiw yes this can be closed. It's proved more useful (and surprising) than I had thought - uncovering many signal processing gremlins. Our challenge moving forward will be to develop the skills and habits necessary to maintain clean signal processing and avoiding ad hoc changes that impact performance without careful thought and design.