Use PlaySound for custom bell audio to preserve mixer volume (#17733)

[aarushisingh04]

summary of the pull request

switch bell sound playback for profile bellSound files from winrt mediaplayer to win32 playsoundw to address #17733, where windows mixer volume for terminal bell audio does not persist across app restarts.

references and relevant issues

• closes Volume Mixer Sound Setting not saved for Windows Terminal #17733

detailed description of the pull request / additional comments

this change updates terminalpanecontent to use playsoundw with snd_filename | snd_async | snd_sentry | snd_nodefault for custom bell audio files.

what changed:

• removed winrt mediaplayer bell playback state and lifecycle code from terminalpanecontent.
• changed _playbellsound(...) to accept a resolved sound path and call playsoundw.
• preserved existing system alias fallback path for non-custom bell sound behavior.
• added safe handling for file: uri-form bell paths by decoding to a filesystem path before calling playsoundw.
• kept normal filesystem path handling intact (for example c:\...) without uri parsing.

rationale:

• issue discussion suggested this may be tied to winrt media player behavior.
• using classic win32 playback aligns with that maintainer hypothesis and is intended to preserve per-app mixer behavior across restarts.

known limitation:

• playsoundw with snd_async is single-channel for this process path, so rapid consecutive bells may interrupt each other. this is existing acceptable behavior for this fix scope and can be revisited separately if needed.

validation steps performed

manual/source validation:

1. verified bellsound resources are resolved by settings model before playback (resolved() path).
2. verified file: uri strings are converted to filesystem paths before playback.
3. verified fallback alias playback path remains unchanged.

recommended manual validation on a dev machine:

1. set a profile bellsound to a local .wav.
2. trigger bell, set terminal app volume to a non-100 value in windows volume mixer.
3. fully close terminal, relaunch terminal, trigger bell again.
4. confirm terminal app mixer volume persists.
5. repeat on windows 10 and windows 11.

pr checklist

• closes Volume Mixer Sound Setting not saved for Windows Terminal #17733
• tests added/passed
• documentation updated
  • if checked, please file a pull request on our docs repo and link it here: #xxx
• schema updated (if necessary)

[aarushisingh04]

@microsoft-github-policy-service agree

[lhecker]

You always copy soundPath into another string. That's unnecessary.

A single call to PathCreateFromUrlW should do the trick for your lengthy path conversion code. The function supports input and output pointer being the same. And URI -> path is naturally always shorter than the input URI. So, this?

if (til::starts_with_insensitive_ascii(soundPath, L"file:"))
{
    // Ensure that the URI has a null terminator.
    std::wstring path{ soundPath }; 
    
    // PathCreateFromUrlW supports writing to the input pointer,
    // and the resulting path can never be longer than the URI.
    const auto ptr = path.data();
    auto len = gsl::narrow<DWORD>(path.size());
    if (FAILED_LOG(PathCreateFromUrlW(ptr, ptr, &len, 0))) {
        return;
    }

    path.resize(len);
}

if (!til::is_legal_path(path))
{
    return;
}

PlaySoundW(filePath.c_str(), nullptr, SND_FILENAME | SND_ASYNC | SND_SENTRY | SND_NODEFAULT);

(Pseudo-code.)

[aarushisingh04]

switched to PathCreateFromUrlW as suggested, removed the winrt uri parsing. also fixed the scoping so filePath is declared before the if block so it's available for the legality check and playsoundw call

[lhecker]

Did you use AI to make this PR? Open the file in a text editor of your choice and convert the line endings to CRLF please. AI tools tend to f line endings up. 😄

[aarushisingh04]

fixed, converted to crlf throughout. sorry about that!

[DHowett]

I'm not sure I understand why we need a URL parser at all. Bell sounds are resolved via IMediaResource, and by the time they get here they should be plain file paths.

[DHowett]

My question about the URI still stands.

[aarushisingh04]

@DHowett

i added the URI handling because of the earlier maintainer suggestion to simplify the conversion logic if file: URIs could reach this layer.

after tracing it back through the settings model though, i agree that this shouldn't be necessary here because BellSound is resolved through IMediaResource and Resolved() should already be a filesystem path by the time it reaches TerminalPaneContent.

if this sounds fine, then i'll remove the URL parsing and keep this code path focused on playing the resolved local path?