[PystoyPlayer]

Key change

Skip shared ChatUI effects and the incorrect-quiz-answer system beep when their macOS output is muted or zero-volume, before allocating or starting an audio player. Resolve the output for every call.

Reason

Starting an inaudible interface sound can request audio output. The supported fix prevents that activation when muted. The shared helper is used by sent and confetti actions; the poll error path now checks the separate default system sound-effects device before beeping. The quiz enum names are not presented as active poll call sites. Calls, user media and the separate notification player keep their own handling.

Screenshot/video result (before/after)

No interface pixels change. The committed recording tests show whether NSSound is allocated/played and whether the beep is invoked. Failure to read the default device intentionally drops this optional sound. NSSound follows the live default output without pinning a previously read UID.

Confirmation

macOS 27.0.1 (26A434), Xcode 27.1, Telegram 13.1.0 (283357), Debug arm64.

python3 tools/tests/muted-sounds/run.py: 20/20 cases pass, compiling the production helper with controlled Core Audio property reads and recording sound construction/playback. Expected and observed: muted/zero-volume outputs allocate no sound, audible outputs play, routing changes are followed without pinning an old UID, and incorrect-answer beeps use the separate system sound-effects device.

python3 tools/tests/muted-sounds/run.py --native: current real Core Audio reads on the muted Mac suppress all ten attempts, with 0 NSSound allocations and 0 play calls. Recording sound construction prevents audible output during this probe. No system volume or routing settings were changed. Physical AirPods/iPhone handoff remains unverified.

The full Debug arm64 client workspace compiled successfully with these shipping sources and real native dependencies on macOS 27.0.1 / Xcode 27.1. It includes other pending changes and local SDK/profile overrides, so this is integration build coverage rather than an independent build of this PR alone.

• I confirm that I have tested the affected behavior and verified that it works properly, or verified the content and links for a documentation-only change.

[macosswift]

Issues:

CONFIRMED: SoundEffects.swift:84-87: playSoundEffectBeep decides whether to play the wrong-answer beep from the mute and volume of the default output device, but the alert sound plays through the system sound device ("Play sound effects through"), so with a muted default output and an unmuted sound-effects device the beep that used to play is now dropped.

CONFIRMED: SoundTests.swift:73: the harness prints its pass summary before the two beep checks run, so it reports "13/13 checks passed" although 15 run and still says all passed when a beep check fails; the description quotes these 13-check numbers and the superseded 13-check result files policy-checks.txt and before-checks.txt are still committed.

[macosswift]

Issues:

• SoundEffects.swift:68, 75: playSoundEffect pins the sound to the output UID read a moment earlier (playbackDeviceIdentifier), where before the PR it followed the default output at play time, so if the default output changes (for example AirPods disconnect) between reading the UID and playing, the sound is bound to a device that is no longer the default: it plays on the old device, or if that device is gone play() fails and the sound is dropped.

[macosswift]

This pull request is not filled in correctly: the confirmation checkbox is missing. Please complete every section as described in CONTRIBUTING.md and update the PR so it can be reviewed.

Issues:

• PR description: the Confirmation section relies on "historical full-client captures", "historical rendered captures above" and a workspace build at a commit that is not among the PR's commits, but the description and the PR contain no captures, and it also lists paid/restricted-reaction and VoiceOver verification that this sound change does not touch.