Same problem here, and I think the scope is wider than the title suggests — this is not Bluetooth-specific.
Environment: macOS 27.0 (26A428), Parallels Desktop 26.3.0 (57392), Windows 11 Pro ARM64 (26200.9457), Parallels Tools 26.3.0.57392.
It fails on every host output device, including the built-in speakers:
iKF-T1, Bluetooth A2DP, 44100 Hz -> fails<br> CoreAudio aggregate device wrapping it, 88200 Hz -> fails<br> MacBook Air Speakers, built-in, 48000 Hz -> fails<br>
All three produce the identical log line:
Failed setting up the frame buffer size with adjusted value (192, default value is 256) for output device. Error code: 0<br> Can't attach pipeline for output device!<br> [CHostAudioBase] failed starting of output audio device<br>
Three unrelated devices, three different sample rates, one identical constant — and note that it says "Error code: 0". That points at Parallels' own handling of the adjusted value rather than at anything device-specific or at the host audio configuration.
Confirmed from the host side as well: while the guest is playing audio, the target output device never starts. kAudioDevicePropertyDeviceIsRunning and kAudioDevicePropertyDeviceIsRunningSomewhere stay 0 for the entire playback. Not a single sample reaches the device.
Regression evidence: my rotated VM logs covering 04-06 through 07-31 (~525k lines) contain zero occurrences of "Can't attach pipeline" or "frame buffer size". The current log covers 07-31 to today and has 22 occurrences, the earliest at 09-16 10:42 — the first VM boot after I upgraded the host to macOS 27.0 on 09-15. Four months clean, broken on the first boot after the upgrade.
Heads-up for anyone troubleshooting this — the audio pipeline is never rebuilt:
Parallels creates the audio pipeline once at VM start and reuses that same object for the whole session, even after the configured output device is changed. I verified it: prlctl set <VM> --device-set sound0 --output <device name> updates the configuration successfully (visible in prlctl list -i), but playback afterwards still fails against the old device's pipeline — the same thread id appears in the log throughout. Changing the Mac's default output device while the VM is running also has no effect on a live session.
So the usual advice "just change the sound output device in the VM settings" cannot work without a VM restart. Suspend + resume is enough: the VM process restarts and rebuilds the pipeline, and the guest session is preserved. That may explain why so many people report that nothing they try helps.
Ruled out so far: guest Bluetooth (the VM's adapter is Parallels' emulated "Virtual Bluetooth Controller" — BTHUSB Event 18 reports it cannot store link keys, so 0 paired devices in the guest is expected and unrelated), the guest audio stack (a single active render endpoint, the Parallels virtual HDA), buffer frame size range (27...1024 on both devices, so the requested 256 is allowed by the device), the recent Windows updates, and the 88.2 kHz sample rate workaround (tested three ways — directly on the device, via an aggregate device, and after a full VM restart — all fail identically).
As far as I can tell there is currently no working workaround. The only thing left that should work is passing a USB audio-class device through to the guest — a USB Bluetooth dongle, the USB receiver of a 2.4 GHz wireless headset, or a USB sound card. Those use the guest's own driver and bypass the virtual sound card entirely.
I see a ticket (#5830492) was already opened from this thread — happy to attach my full parallel.log or generate a problem report if that would help the team. Has anyone found a working configuration, or has this been confirmed as a known defect?
