WIP: Extensions - Add CVSD codec effect for AN/PRC-343

[frankplow]

When merged this pull request will:

• Add a new radio effect for the AN/PRC-343. This radio effect implements Continuously Variable Slope Delta Modulation, as the radio does in real life (the sources for this online are scarce, but I'm fairly certain of this). Signal degradation is also simulated by flipping bits in the encoded bit stream. Here is a demo of the effect*.
• Make various changes to the TS plugin to enable different radios to use different effects.

Given I've done the work to enable it, I may make more changes to the effects so the other radios are more distinct. I think the analogue radios could do with some tweaking to make their effects a bit more realistic. The AN/PRC-154 uses the SRW which I believe uses MELPe, however this algorithm is much more complex than CVSD so I'm not sure I'll have the time.

Feedback is welcome, I'm aware the new effect is much worse quality than the current one, but I think it's much more realistic.

* The effect has changed since this demo was posted. See the comments for more up-to-date demos.

[TheMagnetar]

Thanks for the contribution! I will have a more detailed look of the changes in the next days :)

[frankplow]

f2adeb7 makes some modifications to the sound based on feedback I've gotten. Also turns out that the filter library's Chebyshev type II filter is buggy, so I've switched the anti-aliasing filter to a type I. The effect should be much easier to understand now - a lot more high frequency content comes through on voiced sounds. There's a lot of constants you can fiddle with so if anyone builds this I'd recommend you have a go dialling them in. Here's an updated demo: https://youtu.be/wXOJyhpP--A

[TheMagnetar]

My first comment on this. Can you use fixed size integers (for example std::int16_t)?

[frankplow]

I've done this using shorts as this is what the TS API uses for audio samples (which is a little odd). It's what all the existing effects use also.

[TheMagnetar]

f2adeb7 makes some modifications to the sound based on feedback I've gotten. Also turns out that the filter library's Chebyshev type II filter is buggy, so I've switched the anti-aliasing filter to a type I. The effect should be much easier to understand now - a lot more high frequency content comes through on voiced sounds. There's a lot of constants you can fiddle with so if anyone builds this I'd recommend you have a go dialling them in. Here's an updated demo: https://youtu.be/wXOJyhpP--A

I would say that while the middle signal quality range sounds ok. The lower end sounds too good and the message can be heard across even at 5% signal quality.

[frankplow]

I would say that while the middle signal quality range sounds ok. The lower end sounds too good and the message can be heard across even at 5% signal quality.

I should have been a bit more clear with this in the demo, but all those samples are at 0dB. In-game by the time the signal quality gets to around 15%, the volume is lower than the sensitivity of the AN/PRC-343, so the transmission is quiet and intermittent on top of the distortion. The existing effect is still understandable all the way down at 1% signal quality if the volume is sufficiently high, so I've just tried to match that behaviour.

[frankplow]

04b508d fixes a crash which would occur if getChannelData did not return a modulation type for a specific radio. I've also ensured all ACRE radios will always return this.

It seems there's been some discussion on whether getChannelData and its derivatives should return data that is the same for all channels on that radio (see the changes to sys_sem52sl and sys_sem70). I've taken the liberty of selecting the approach of sending this data - I think that this is more elegant than requiring extra logic downstream to ensure all the necessary data is present, at only the cost of returning a couple more values than is strictly necessary in some cases. There are still a couple values which aren't given in some cases, for example the AN/PRC-343 does not return CTCSS frequencies as it's a digital radio, but I think logic must have gone wrong elsewhere for this to cause issues now.

[jonpas]

It seems there's been some discussion on whether getChannelData and its derivatives should return data that is the same for all channels on that radio

Yeah, that's good. :)

[Quailsnap]

Just lending another ear -- I think the signal quality is too degraded for 100% and 80%. Excessive noise. I agree that the middle is alright. I am no radio expert, however, and this is just based on brief references from YouTube.

Edit: (i.e. one you may have already seen )