Voice memos (isAudioMessage: true) produce broken 0-second unplayable audio

[mwmacmahon]

Description

When sending an audio attachment with isAudioMessage: true and method: private-api, the recipient receives a voice bubble that shows 0 seconds duration, has an identical waveform regardless of content, and is unplayable. The same audio file sent as a regular attachment plays correctly.

Environment

• BlueBubbles Server: 1.9.9
• macOS: 26.2.0 (Tahoe)
• Private API: Enabled

Steps to Reproduce

1. Have any valid MP3 file (I used ffmpeg sine waves at 3s and 10s)
2. Send via the attachment API:

curl -X POST "https://<SERVER>/api/v1/message/attachment?password=<PASSWORD>" \
  -F "attachment=@test.mp3;type=audio/mpeg" \
  --form-string "chatGuid=<CHAT_GUID>" \
  -F "name=test.mp3" \
  -F "tempGuid=temp-$(date +%s)" \
  -F "method=private-api" \
  -F "isAudioMessage=true"

3. Voice bubble arrives but shows "0 seconds", flat waveform, won't play

Expected Behavior

Voice bubble plays audio with correct duration and waveform.

Actual Behavior

Voice bubble is broken — 0s duration, identical waveform regardless of content, unplayable.

Test Results

I tested the same audio files across three scenarios to isolate the issue:

• Group A (baseline): Regular attachments without isAudioMessage — confirms the audio files are valid
• Group B: Same files sent as voice memos with isAudioMessage=true — the broken case
• Group C: Voice memo flag set, but with apple-script or no method instead of private-api — isolates the delivery path

All tests used the same 3s sine wave MP3 unless noted. The 10s variant rules out duration as a factor.

Test	Format	Method	isAudioMessage	Result	Playable
A1	MP3 3s	private-api	false	MP3 attachment, 3s	✅
A2	MP3 10s	private-api	false	MP3 attachment, 10s	✅
B1	MP3 3s	private-api	true	Voice bubble, 0s	❌
B2	MP3 10s	private-api	true	Voice bubble, 0s	❌
B3	CAF (AAC) 3s	private-api	true	Voice bubble, 0s	❌
C1	MP3 3s	apple-script	true	CAF attachment, 3s	✅
C2	MP3 3s	(none)	true	CAF attachment, 3s	✅

C1/C2 are key: the same 3s MP3 from B1 is converted MP3→CAF by the server and plays correctly when sent via apple-script or default method. The bug is specifically in the private-api + isAudioMessage=true code path. B3 (pre-converted CAF) is also broken, so the issue is downstream of format conversion.

Additional Info

API returns 200 with successful conversion (e.g. 49KB MP3 → 271KB CAF, UTI com.apple.coreaudio-format), but the resulting voice memo is broken.

[mwmacmahon]

Root Cause Found: Wrong Audio Codec

After more investigation, the root cause is in convertMp3ToCaf() — it converts to PCM Int16 at 44100Hz:

afconvert -f caff -d LEI16@44100 -c 1

But iMessage voice memos require Opus at 24000Hz. Confirmed by inspecting real voice memos created natively on the same machine:

# BlueBubbles-created voice memo (broken):
Data format: 1 ch, 44100 Hz, Int16
Duration: 3.03 sec, Bytes: 267264

# Real iMessage voice memo (working):
Data format: 1 ch, 24000 Hz, opus
Duration: 5.46 sec, Bytes: 21810

Proof

Pre-converting to Opus CAF before sending to the BB API produces working, playable voice memos with correct duration and waveform:

# Convert to the format iMessage actually expects
afconvert -f caff -d opus@24000 -c 1 input.mp3 output.caf

# Send the .caf directly — BB skips conversion for non-MP3 files
curl -X POST ".../api/v1/message/attachment?password=..." \
  -F "attachment=@output.caf;type=audio/x-caf" \
  --form-string "chatGuid=..." \
  -F "name=voice.caf" \
  -F "tempGuid=temp-$(date +%s)" \
  -F "method=private-api" \
  -F "isAudioMessage=true"

This also explains why B3 in my original report (pre-converted AAC CAF) was still broken — AAC is also the wrong codec. Only Opus works.

Suggested Fix

Change the afconvert flags in FileSystem.convertMp3ToCaf() from:

-f caff -d LEI16@44100 -c 1

to:

-f caff -d opus@24000 -c 1

macOS afconvert natively supports Opus output in CAF containers (afconvert -hf shows 'opus' in the caff data formats list).

---

Also noting a minor race condition in convertAudio() (utils.ts): the fs.existsSync(newPath) check isn't atomic, so concurrent webhook dispatches trigger duplicate conversions. The first succeeds; the rest get -54 errors. Not blocking — just noisy in logs.

[mwmacmahon]

I've been debugging this from the OpenClaw side and found the root cause.

BB's convertMp3ToCaf() in src/server/fileSystem/index.ts uses:

afconvert -f caff -d LEI16@44100 -c 1

This produces PCM Int16 at 44100Hz. But iMessage voice memos require Opus at 24000Hz mono in a CAF container. The PCM CAF gets rejected — iMessage displays 0-second unplayable audio.

Evidence from the same Mac:

# BB-created voice memo (broken):
Data format: 1 ch, 44100 Hz, Int16

# Real iMessage voice memo (working):
Data format: 1 ch, 24000 Hz, opus

The fix would be changing the afconvert flags to:

afconvert -f caff -d opus@24000 -c 1

I've confirmed this works — sending a CAF with Opus@24000Hz via the BB API with isAudioMessage: true produces a correctly playable voice bubble.

(The -54 afconvert errors in logs are a separate TOCTOU race condition in convertAudio() on fs.existsSync() — cosmetic, not related to the codec issue.)

[amzzzzzzz]

GitHub Issue #773 Comment Draft

---

Our Use Case

We're building bi-directional voice memo support for an AI assistant (OpenClaw) that communicates via BlueBubbles. The goal is async voice conversations - user sends voice memo from iPhone → AI transcribes + responds → AI sends voice memo back.

Receiving voice memos works perfectly (BlueBubbles converts incoming .caf to .mp3, OpenClaw transcribes via Whisper). The blocker is sending native voice memos back.

Environment

• BlueBubbles Server: 1.9.9
• macOS: 26.3.0 (Tahoe)
• Private API: Enabled, helper connected
• Sending from: Node.js API client

What We Tried

Test 1: isAudioMessage: true + method: private-api

curl -X POST "http://127.0.0.1:1234/api/v1/message/attachment" \
  -F "attachment=@voice.mp3" \
  -F "chatGuid=any;-;+1234567890" \
  -F "isAudioMessage=true" \
  -F "method=private-api"

Result: Request hangs/times out. No response after 60+ seconds.

Test 2: isAudioMessage: true + method: apple-script

curl -X POST "http://127.0.0.1:1234/api/v1/message/attachment" \
  -F "attachment=@voice.mp3" \
  -F "chatGuid=any;-;+1234567890" \
  -F "isAudioMessage=true" \
  -F "method=apple-script"

Result: Returns 200, attachment sent. Server converts MP3→CAF. BUT: arrives as file attachment, not voice bubble. Response shows "isAudioMessage": false.

Test 3: isAudioMessage: true + no method (default)

Same as Test 2 - works, but arrives as attachment, not voice bubble.

Test 4: Pre-converted .m4a with isAudioMessage: true

Same behavior as MP3 - works as attachment, not as voice bubble.

Server Logs

With method: apple-script:

Sending attachment "voice.mp3" to any;-;+1234567890
Adding await for chat: "any;-;+1234567890"; attachment: voice.caf
[ActionHandler] Sending AppleScript text using fallback script...
New Message from You, <No Text>; Attachments: 1
Converting attachment, voice.caf, to an MP3...

The server successfully converts and sends, but the message isn't marked as an audio message.

Code Analysis

Looking at BlueBubblesHelper.m, the send-attachment handler:

} else if ([event isEqualToString:@"send-attachment"]) {
    NSString *filePath = data[@"filePath"];
    NSURL * fileUrl = [NSURL fileURLWithPath:filePath];
    IMFileTransfer* fileTransfer = [BlueBubblesHelper prepareFileTransferForAttachment:fileUrl filename:[fileUrl lastPathComponent]];
    // ... creates attributed string with file transfer ...
    [BlueBubblesHelper sendMessage:(data) transfers:@[[fileTransfer guid]] attributedString:attachmentStr transaction:(transaction)];

The isAudioMessage parameter from data is passed but never used in this code path. The helper creates a standard file transfer regardless of whether it's an audio message.

Hypothesis

For native voice bubbles, the helper likely needs to:

1. Set a special attribute on the IMMessage (e.g., __kIMIsAudioMessageAttributeName)
2. Or use a different IMCore method for audio messages
3. Or set specific properties on the IMFileTransfer

The Private API path (method: private-api) seems to attempt this but produces broken 0-second audio (as the original reporter found). The AppleScript path works for playback but doesn't produce voice bubbles.

We're Happy to Help Test

We have:

• ✅ macOS 26 Tahoe test environment
• ✅ BlueBubbles 1.9.9 with Private API enabled
• ✅ Automated testing via API
• ✅ Ability to test different audio formats (MP3, M4A, CAF)

If you point us to a test build or branch with a potential fix, we can test immediately and provide detailed feedback.

This feature would unlock a really compelling use case (AI voice assistants via iMessage), so we're motivated to help get it working! 🎤

---

Post to: #773