Voice PE still incompatible with ESPHome 2025.3.x+ due to transfer_data_to_sink error — fix ETA

[maiden marsh]

I’ve been using Home Assistant Voice PE successfully with ESPHome 2025.2.x, but after updating to 2025.3.x (and now 2025.4.x), I’ve been unable to compile due to this error:

error: no matching function for call to 'transfer_data_to_sink(TickType_t, bool)'

It appears to be coming from mixer_speaker.cpp, which is still calling the old two-argument version of transfer_data_to_sink() — even though ESPHome core deprecated that signature several releases ago.

I’ve tested this across the latest dev branches, and the issue still exists. Are there any plans to update the Voice PE repo to reflect this ESPHome core change?

Questions:
• Is an official fix in the pipeline?
• Should we be holding on 2025.2.x indefinitely, or is a patch planned soon?
• Is the Voice PE team waiting on a fix from core ESPHome instead?

[spark ermine]

are you using a customised firmware? what are you doing that's different?

[maiden marsh]

Yes. I’m using a slightly customized version of the firmware based on RobMeades’ fork (https://github.com/RobMeades/home-assistant-voice-pe ) which I merged with the latest upstream dev branch of the official esphome/home-assistant-voice-pe repo. The goal of robmeades fork was to enable support for OpenWakeWord.

• Enabled OpenWakeWord

• Modified the config so the rotary encoder no longer affects the voice assistant volume.

• Replaced the internal LED volume logic to reflect the volume of an external Snapcast player, not the internal media player.

• Changed noise suppression value

All changes were layered on top of the upstream dev branch — no C++ logic was added or modified directly.
The breaking compile error (transfer_data_to_sink(TickType_t, bool)) happens before any YAML-level customization kicks in — it fails at build time due to an outdated call in mixer_speaker.cpp, which is still present in the official repo. I’ve seen a few comments and issues posted on the community forum and GitHub but no official response as to whether it will be addressed.

[spark ermine]

I should really get a spare PE for messing with stuff like this...
but in any case: i beleive the problem is likely to be coming from the custom components.
the VPE uses some components with different functionality that have not been unstreamed to mainline ESPHome (yet)

the external_components section in the custom repo yaml is pointing to its own repo and not using the latest versions of the custom components (its also added a custom "audio" component) I suspect that when you have merged code bases there is some conflict between the code and the custom component verions being used

that is likely the source of the issue your having

[maiden marsh]

Great catch. Yes, I’ve seen the difference in the external_components block as well. RobMeades’ fork adds a custom audio component in addition to the standard ones from the official ESPHome Voice PE repo. And I agree: if that component is overriding or extending core functionality (like mixer_speaker or audio pipelines), it could easily be a source of conflict.

That said, here’s what I’ve verified:

I originally started with RobMeades’ fork, then merged upstream esphome/home-assistant-voice-pe@dev into my own fork to keep it up to date.

Regardless of whether I use RobMeades’ repo or the upstream ESPHome repo as the source for external_components, I hit the same compile error with ESPHome 2025.3+:

error: no matching function for call to 'transfer_data_to_sink(TickType_t, bool)'

That’s coming from a file named mixer_speaker.cpp, which is included in both repos under esphome/components/mixer/speaker. This file still uses the old method signature with two arguments, but the core ESPHome AudioSinkTransferBuffer class now only accepts one (introduced in ESPHome 2025.3.0+)

This error happens even with a stock clone of either repo, no custom YAML changes at all

So your point holds — the error isn’t from my own changes, it’s from the fact that the repo is still bundling (or referencing) an outdated version of mixer_speaker, which no longer compiles against the current ESPHome core.

If audio is doing anything sneaky under the hood (or if it’s pulling in older internal APIs), that might be compounding things. But as of now, even switching to the upstream ESPHome repo still fails to compile under 2025.3.x, which suggests that neither version has been updated to match ESPHome’s latest internal changes.

I’d be happy to help patch this and PR it if needed — just trying to confirm whether the core team plans to own the fix or if the community should push one forward.

[spark ermine]

I would also keep in mind that esphome dev branch has probably diverged a little bit from stable as its getting closer to a release. I expect we will see 2025.5 BETA tomorrow.
also all the components talk to each other so any outdated version could cause errors in the others.

currently custom compnent stuff from VPE is in the process of being upstreamed so there is definetly possibility of issues throughout this process. you could open an issue to ask about specific crashes but realistically waiting for things to settle down before customising components may be whats needed unless your going to stay on top of all the impacting changes.

[maiden marsh]

Yes I’ve just been sitting on my hands waiting for an update. Will continue to do so. Will also consider opening a GitHub issue, though I believe I saw others posted. Thanks for the response.