Eleven labs | Friends of the Crustacean 🦞🤝 | Page 1

scenic path Apr 12, 2026, 9:16 PM

#

Had eleven labs voice working on the Mac OpenClaw App last night and today it’s back to the robot sounding voice… fixed for a hot second but mostly ugly sounding. Any ideas in a fix? My assistant could not figure it out

bronze furnaceBOT Apr 12, 2026, 9:16 PM

#

terse canopyBOT Apr 12, 2026, 9:16 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

rapid bayBOT Apr 12, 2026, 9:18 PM

#

Yep, that usually means OpenClaw is falling off ElevenLabs and using a fallback voice.

First, can you paste:

openclaw --version

Then check which voice path you’re using:

Normal reply TTS: /tts status
or
```
openclaw infer tts status --json
```
Mac app Talk mode: /talkvoice status

#

A few likely fixes:

Force ElevenLabs explicitly
- reply TTS: messages.tts.provider: "elevenlabs"
- Talk mode: talk.provider: "elevenlabs"

Disable the robotic fallback while debugging

messages: {
  tts: {
    providers: {
      microsoft: { enabled: false }
    }
  }
}

#

Run doctor, since Talk config changed and legacy talk.voiceId style config is auto-migrated now:
```
openclaw doctor
```
Restart the gateway/app after changing config.

Relevant docs:

If you paste openclaw --version plus /tts status or /talkvoice status, I can tell you the exact config line to change.

scenic path Apr 13, 2026, 1:06 AM

#

tried everything. Still sounding like a computer. I tyoed the screen shots into the web UI

rapid bayBOT Apr 13, 2026, 1:07 AM

#

I’m pretty sure this is a wrong voice bucket issue.

On the Mac app, Talk mode voice is not the same thing as normal reply TTS.

Mac app / Talk mode uses talk.*
Regular spoken replies use messages.tts.*

So if you changed the TTS settings in the Web UI, the Mac app can still sound robotic because Talk mode is reading from a different config.

For Mac Talk mode, the config should look like this:

{
  talk: {
    provider: "elevenlabs",
    providers: {

#

      elevenlabs: {
        apiKey: "YOUR_ELEVENLABS_KEY",
        voiceId: "YOUR_VOICE_ID",
        modelId: "eleven_v3",
        outputFormat: "mp3_44100_128",
      },
    },
  },
}

Also run this once:

openclaw doctor

#

That matters because old talk.voiceId style config is legacy now and gets migrated to talk.provider + talk.providers.<provider>.

Then restart the gateway/app.

Two things I still need from you, in text, not screenshots:

openclaw --version

and

/talkvoice status

If you paste those, I can usually spot the bad line fast.

#

Docs:

scenic path Apr 13, 2026, 1:51 AM

#

Okay let me feed this into my web UI and report back. Thanks!

rapid bayBOT Apr 13, 2026, 1:51 AM

#

Sounds good, paste the text output when you have it, especially:

openclaw --version
/talkvoice status

If it’s still cursed after that, we’ll pin it down 🙂

scenic path Apr 13, 2026, 1:56 AM

#

provider: elevenlabs
talk.providers.elevenlabs.voiceId: pFZP5JQG7iQjIQuC4Bku
elevenlabs.apiKey: sk_b38…

#

Stil not working

rapid bayBOT Apr 13, 2026, 1:57 AM

#

I think I see the bug.

talk.providers.elevenlabs.voiceId is a valid path, but elevenlabs.apiKey is not the Talk-mode path.

For the Mac app / Talk mode, it should be:

talk.provider: "elevenlabs"
talk.providers.elevenlabs.voiceId: "pFZP5JQG7iQjIQuC4Bku"
talk.providers.elevenlabs.apiKey: "..."

If you want normal spoken replies too, that is a separate config block:

messages.tts.provider: "elevenlabs"

#

messages.tts.providers.elevenlabs.apiKey: "..."

So, if elevenlabs.apiKey is literally what got set, I’d fix that first. Then run:

openclaw doctor
openclaw gateway restart

Docs:

Also, small security note: if the full ElevenLabs key got pasted anywhere public, rotate it.

#

Okay, we’re at the point where I need the raw text output, not a summary.

Please paste these exactly:

openclaw --version
openclaw status --all

and also:

/talkvoice status

If you can, paste the redacted talk block from ~/.openclaw/openclaw.json too, like:

#

talk: {
  provider: "...",
  providers: {
    elevenlabs: {
      voiceId: "...",
      apiKey: "***",
      modelId: "...",
      outputFormat: "..."
    }
  }
}

Don’t paste the full API key.

Reason I’m asking: if this was edited through the Web UI assistant, it may have written the right idea to the wrong config path, and the exact text will show that fast.

scenic path Apr 13, 2026, 2:04 AM

#

Here's everything for Krill to paste into Discord:

openclaw --version:

Copy
OpenClaw 2026.4.11 (769908e)
openclaw status --all (Channels section):

Copy
Telegram | ON | OK | token config (sha256:2fb22ad0 · len 21) · accounts 1/1
(Telegram is looping on deleteWebhook 404 errors — attempt 6/10)

/talkvoice status:

Copy
provider: elevenlabs
talk.providers.elevenlabs.voiceId: pFZP5JQG7iQjIQuC4Bku
elevenlabs.apiKey: sk_b38…
talk block from openclaw.json:

Paste that to Krill and let's see what they say!

rapid bayBOT Apr 13, 2026, 2:05 AM

#

Nice, that helps.

A couple things:

The Telegram deleteWebhook 404 is unrelated to your Mac Talk voice issue.
What you pasted is still the status summary, not the actual config, so we’re still missing the most important bit.

Please run this exact command and paste the output:

openclaw config get talk

That will show whether the key is really under the canonical Talk path.

Also, on 2026.4.11, I’d run the repair pass once because Talk legacy aliases were cleaned up recently:

#

openclaw doctor --fix
openclaw gateway restart

If it’s still robotic after that, next step is:

openclaw logs --follow

Then toggle Talk mode once and paste any lines mentioning talk, tts, or elevenlabs.

I think we’re close. The likely problem is still “right provider, wrong config shape.”

scenic path Apr 13, 2026, 2:08 AM

#

openclaw config get talk output:

openclaw doctor --fix — no errors.

openclaw logs --follow — zero log lines mentioning talk, tts, or elevenlabs when Talk Mode is togled. The Mac app never calls the gateway for TTS. It's using AVSpeechSynthesizer locally.

rapid bayBOT Apr 13, 2026, 2:10 AM

#

Ah, okay, that changes the diagnosis.

I checked the current macOS code. Talk Mode can fall back to local AVSpeechSynthesizer, so the gateway showing no TTS calls is actually consistent with the failure path.

What triggers that fallback on macOS is basically:

missing ElevenLabs API key
missing/unresolved voiceId
or a likely Mac-side config parsing miss, where the app ignores normalized Talk config and drops to system voice

The log lines I’d want from the Mac app logs are these exact ones:

talk missing ELEVENLABS_API_KEY; falling back to system voice
talk missing voiceId; falling back to system voice
talk config ignored: normalized payload missing talk.resolved

So next step is Mac app logging, not gateway logging:

#

Debug pane → Logs → App logging → Verbosity
enable Write rolling diagnostics log (JSONL)
reproduce once
then check ~/Library/Logs/OpenClaw/diagnostics.jsonl

Docs: https://docs.openclaw.ai/platforms/mac/logging

If you hit one of those lines, I’d treat this as app-side bug / regression, not “bad ElevenLabs settings”, and file it here with the redacted log snippet + your version (2026.4.11):
https://github.com/openclaw/openclaw/issues

I’m glad we found the right layer, at least.

scenic path Apr 13, 2026, 2:13 AM

#

Copy
talk config provider=elevenlabs voiceId=pFZP5JQG7iQjIQuC4Bku modelId=eleven_v3 apiKey=true
talk TTS request voiceId=pFZP5JQG7iQjIQuC4Bku chars=92
talk TTS synth timeout=20.0s
talk TTS failed: audio playback failed; falling back to system voice
talk system voice start chars=92
Config is correct. ElevenLabs is called. But audio playback fails. This is a Mac app bug — file it at https://github.com/openclaw/openclaw/issues with these log lines!

rapid bayBOT Apr 13, 2026, 2:14 AM

#

Yep, those logs are the smoking gun.

What they prove:

config is correct
ElevenLabs is actually being called
the failure happens after synthesis, during macOS playback
then the app falls back to the robot/system voice

So this is not an API key or voiceId problem anymore.

One last workaround I’d try before filing an issue:

talk.providers.elevenlabs.outputFormat: "mp3_44100_128"

Then restart the app/gateway.

#

Reason: macOS Talk defaults to pcm_44100, and forcing MP3 can dodge some local playback weirdness.

Docs: https://docs.openclaw.ai/nodes/talk

If it still fails after forcing MP3, I’d file it as a Mac app bug here and include exactly those log lines plus your version (2026.4.11):
https://github.com/openclaw/openclaw/issues

If the MP3 workaround fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

scenic path Apr 13, 2026, 2:15 AM

#

outputFormat: "mp3_44100_128" is already there. So Krill's workaround is already applied and it's still failing. This is a confirmed Mac app bug.

Dale, we need to file a GitHub issue. Let me draft it — you can paste it at https://github.com/openclaw/openclaw/issues/new:

Title: Talk Mode: ElevenLabs TTS fails with "audio playback failed" and falls back to system voice

Version: 2026.4.11-beta.1 (Mac app) / Gateway 2026.4.11

Config:

Log evidence:

Copy
talk config provider=elevenlabs voiceId=pFZP5JQG7iQjIQuC4Bku modelId=eleven_v3 apiKey=true
talk TTS request voiceId=pFZP5JQG7iQjIQuC4Bku chars=92
talk TTS synth timeout=20.0s
talk TTS failed: audio playback failed; falling back to system voice
talk system voice start chars=92
Notes: Config is correct. ElevenLabs is being called successfully. Failure occurs during audio playback on macOS. MP3 outputFormat already set. Consistently falls back to system voice on every Talk Mode response.

rapid bayBOT Apr 13, 2026, 2:16 AM

#

Yep, I agree, that’s a real Mac app bug, not bad config.

Your draft is solid. I’d paste this:

## Summary

Talk Mode on the Mac app fails to play ElevenLabs audio and falls back to the system voice.

## Versions

- Mac app: 2026.4.11-beta.1
- Gateway: 2026.4.11

## Expected

#

Talk Mode should play the ElevenLabs voice.

## Actual

Talk Mode logs an audio playback failure, then falls back to the local system voice.

## Config

- `talk.provider: "elevenlabs"`
- `talk.providers.elevenlabs.voiceId: "pFZP5JQG7iQjIQuC4Bku"`
- `talk.providers.elevenlabs.modelId: "eleven_v3"`
- `talk.providers.elevenlabs.outputFormat: "mp3_44100_128"`

## Log evidence

```text

#

talk config provider=elevenlabs voiceId=pFZP5JQG7iQjIQuC4Bku modelId=eleven_v3 apiKey=true
talk TTS request voiceId=pFZP5JQG7iQjIQuC4Bku chars=92
talk TTS synth timeout=20.0s
talk TTS failed: audio playback failed; falling back to system voice
talk system voice start chars=92


## Notes

- Config is correct
- ElevenLabs is being called successfully
- Failure happens during audio playback on macOS
- `outputFormat: "mp3_44100_128"` is already set
- Reproduces consistently on every Talk Mode response

Issue link: https://github.com/openclaw/openclaw/issues/new

#

Two useful extras if you have them:

whether audio output was built-in speakers vs Bluetooth/AirPods
whether the app was installed from a release build or source

And definitely don’t include the full API key.

#Eleven labs