Use multiple threads to better spread CPU workload

[philpem]

I've been trying to run HackTV on a Raspberry Pi 4 B+ (4GB RAM).

This setup works fine when showing a test card at an 11MHz or 14MHz sample rate, but when Videocrypt is enabled the Pi can't keep up (HackRF suffers underruns).

It appears that all the processing work is being done in a single thread - one of the Pi's CPU cores is fully saturated while the other three aren't doing anything.

Could HackTV be enhanced to do its processing across multiple threads?

[captainjack64]

ffmpeg decoding is done in a separate thread, though most other things are in a single one.

[fsphil]

The bottleneck I kept hitting on my older machine was memory bandwidth, rather than processing power. I'm not sure multiple threads would help in that case, but it certainly wouldn't harm it. Audio modulation, video modulation, and the FIR filters could potentially be moved into their own threads quite easily.

One potential quick fix for the Pi might be to disable NICAM audio with --nonicam.

[philpem]

I did notice that enabling the FIR filter caused underruns on my laptop (which usually handles HackTV quite well) - and that's a reasonably specced machine (Thinkpad X220). So this might have benefits on desktops too.

I'll try without NICAM and see how I get on - is that known to be particularly computationally intensive?

EDIT: Disabling NICAM significantly improved things. The Pi can happily transmit a test card with Videocrypt-1 using the HackRF.

[fsphil]

I don't think NICAM is any more intensive than FM audio, but it's often just enough to push slower machines over the edge.

I believe the main issue for performance at the moment are the Y, U and V level lookup tables. They're very large, and the lookups are often fairly random so difficult for the CPU to predict or cache.

[neo7530]

D2mac fm works quite well up to 20mhz sampling rate on raspi 4. Disabling nicam on pal g works well to. But only with testpattern