[aydiler]

Fixes #711.

Problem

get_worker_fn handles the control channel with if let Ok(..) = controls.try_recv(), so it never notices TryRecvError::Disconnected. When the host drops a DfPlugin (LADSPA cleanup), control_tx is dropped but the detached worker thread keeps polling its input queue and sleeping forever.

This matters in practice with PipeWire's filter-chain, which re-instantiates the plugin whenever the graph quantum changes, i.e. every time an app starts or stops playback. On my desktop a call-mic filter-chain running deep_filter_mono had accumulated about 710 threads after 7 days of uptime, using about 110% CPU, and the live instance logged constant Underrun detected ... Processing too slow!.

Fix

Match on try_recv() and break out of the worker loop on Disconnected. This is a behavioural no-op while the plugin is alive.

Testing

PipeWire 1.6.10, deep_filter_mono (default DeepFilterNet3_ll model) in a filter-chain at 48 kHz:

• Before: each pw-metadata -n settings 0 clock.force-quantum <512|1024|256> left one more thread in the host process (5 → 6 → 7 → 8).
• After: thread count stays constant across repeated quantum changes, both idle and while recording from the filtered source; the recorded audio is normal.