Confirm the actual audio environment
First establish that the desktop uses PipeWire and identify the player and output device involved. A guide for this audio graph should not be imposed on a different sound server or a television’s unrelated settings. Choose an authorised sample and describe whether the problem is silence, clicks, delay or another specific symptom. These observations need different investigations.
Use the publisher’s field definitions
PipeWire documents pw-top as a dynamic view of nodes and devices, with driver and follower relationships. The columns include status, quantum, rate, errors and negotiated format. Record the relevant node and its current state instead of copying another machine’s row. A suspended or idle node is a different observation from the intended playback node running during the fault.
Keep rates and timing separate
The quantum and rate describe graph scheduling together; the negotiated hardware or stream format is shown separately. A graph rate should not automatically be reported as the original file’s sample rate or as a complete end-to-end delay. Preserve the actual field names with the values so a maintainer can interpret what the tool measured, including whether the observation concerns a driver or a follower.
Avoid premature tuning
A counter or timing field supplies evidence, not an instruction to paste configuration overrides from another system. Capture a baseline, reproduce the narrow symptom and compare the relevant changes with the distribution or application maintainer’s documented process. Keep any private node names out of public reports when unnecessary. No PipeWire configuration change, sound-device test or UK IPTV integration is asserted by this reference.