voice: add on-device audio recording with playback and SDK API

[julpel8]

Summary

Adds on-device audio recording to flash, playback through the watch speaker, and deferred transcription through the phone.

Recordings use the existing Speex codec and can be created without a phone connection. Once Bluetooth is available, an app can send a stored recording through the existing dictation
transport and receive the transcription result.

This addresses the offline-recording use case described in #719.

Refs #719

What's included

• On-device microphone recording

  • Stores Speex-encoded audio in PFS.
  • Uses pre-allocated temporary files to avoid flash erases during capture.
  • Compacts recordings to their final size when stopped.
  • Supports storage quotas, enumeration, deletion, validation, and cleanup.
  • Enforces recording ownership for third-party apps.
  • Keeps recording and live dictation mutually exclusive.

• Speaker playback

  • Decodes stored Speex frames to 16 kHz PCM.
  • Streams audio through the existing speaker service.
  • Isolates playback sessions from stale callbacks.

• Deferred transcription

  • Streams stored Speex frames to the phone without transcoding.
  • Paces transfers to prevent send-buffer overflow and dropped frames.
  • Reports upload progress to the UI.
  • Prevents deletion of a recording while it is being transcribed.
  • Delivers results through the existing dictation event path.

• SDK API

  • Adds APIs to start, stop, cancel, query, enumerate, play, delete, and transcribe recordings.
  • Includes the required syscalls and exported SDK symbols.
  • Bumps the SDK revision.
  • Returns transcription results asynchronously through a callback.

• Settings test interface

  • Adds a “Record audio (beta)” page for recording, playback, transcription, and deletion directly on the watch.
  • This currently serves as a test interface. Whether it should remain as a
    user-facing Voice Memos interface is an open question.

Open questions

• Recording lifecycle: Should recordings remain stored until the app
  deletes them, be deleted automatically after transcription, or be managed
  by an OS retention policy? What should happen when the owning app is
  uninstalled or the recording storage quota is reached?

• Audio quality: Should recording quality remain configurable through a
  system menu, use a fixed default, or be exposed to apps through the SDK?
  Should recording and playback gain remain configurable as well?

• Storage information: Should the watch display the storage used and
  available for recordings? If so, should this represent the dedicated
  recording quota or the actual free flash space? Should this information also
  be exposed through the SDK?

• Settings UI: Should the current settings page remain available as a
  user-facing Voice Memos interface, or should it be removed once SDK
  integration is validated?

Validation

• Built for obelix@pvt (Pebble Time 2).
• Tested on real Pebble Time 2 hardware:
  • record and stop;
  • display the saved recording with its duration and size;
  • play audio through the speaker;
  • transcribe a stored recording;
  • delete recordings.
• Registered and ran the voice-recording playback unit tests successfully.

Screenshots

Notes for reviewers

This PR covers recording, playback, and deferred transcription as one end-to-end feature. It is relatively large and can be split into separate reviewable changes if preferred.

The capture stop path still shares the microphone tail-drop behavior described in #1423: residual PDM data and the final partial Speex frame are not flushed.

[julpel8]

@jplexer @gmarull My PR is heavy, should I split it in 3 PR (record, playing and transcribe) ?

[ericmigi]

cool! keep in touch with @jplexer as they will help merge this if it's good enough

[ericmigi]

would be cool to see an easy to use companion pkjs side that receives/decodes/streams audio from watch

[julpel8]

Is this heavy battery consumption related to audio feature ?

[ericmigi]

are you using a debug or release build? debug builds enable UART RX which is very high power consumption

[julpel8]

are you using a debug or release build? debug builds enable UART RX which is very high power consumption

Yes, I don't set CONFIG_RELEASE. Thank you !

[eiis1000]

Would really love to see this merged! There are so many apps I want to make with this feature...

[ericmigi]

we're tracking it! just haven't had time yet sorry

[baibhavbista]

This is fantastic! offline on-device recording is going to be a really welcome addition.

However, I think there's a missing piece: audio_recording_transcribe() already transports the stored recording to the phone, but only exposes Pebble's transcript — there's currently no supported way for the initiating app (or its PKJS companion) to receive the recording itself. And a class of apps needs the audio, not just text.

Two reasons from my own use case (I'm building a Roam Research capture watchapp for PT2) that specifically need the recording, not just a transcript:

• My own transcription — the built-in model struggles with my accent, so I need to re-transcribe the audio on my own backend.
• Storing the recording — I want to save the recording in Roam alongside a timestamped transcript, so it's replayable and navigable later. In our equivalent apple watch app, this recording has proved to be a godsend in noisy situations where the AI misspells a lot of stuff.

Others in #719 have asked for the same (saving audio + transcript), so exposing an API to get the audio out would help a range of apps, not just mine.

One possible shape (drafted with AI assistance; the technical claims were checked against the PR source): a read API like audio_recording_read(id, offset, buf, len) (plus the codec params) that lets an app pull the stored Speex frames and forward them to a server. That said, see my follow-up below for a refinement I'd actually prefer, aligned with @ericmigi's earlier comment.

Happy to help in any way I can: whether testing or by contributing a stab at a follow-up PR (DCO + AI-disclosure understood). Thank you!

cc @ericmigi @jplexer to hear your thoughts on my request

[baibhavbista]

Following up on my comment above, I just noticed @ericmigi's earlier note about "an easy to use companion pkjs side that receives/decodes/streams audio from watch." That's exactly the shape that would work for me, and it's a better fit than the read API I mentioned above.

(Below is from Claude, so please take with grain of salt again)

---

audio_recording_transcribe() already streams the stored recording to the phone — if that same transport could hand the audio to the initiating app's PKJS companion (decoded, or as frames + codec metadata) instead of only the built-in transcriber, that would be all I need. PKJS could own the HTTP upload to my backend and return the result to the watch over AppMessage. An app-scoped export/stream that preserves the recording ID (AudioRecordingInfo.id) as a correlation ID, plus completion/error reporting, would be enough.

It also preserves this PR's offline model: keep the recording on-watch until the export is acknowledged, then the app can delete it.

(A byte-read API like audio_recording_read() would also work, but it'd make every app re-chunk the audio through AppMessage even though this PR already has a native transport — so I'd favor the companion stream if that matches where you're headed.)

---

Happy to help spec, test, or contribute a follow-up PR.

[julpel8]

Thanks @baibhavbista!

Getting the raw audio out makes a lot of sense.

I’ve actually already forked Brain Dump by @adrienthiery and got it listing the on-device recordings via audio_recording_list().
Adrien was interested in this feature too. I’ll add the PKJS code to ship the audio out to a backend in my fork branch soon.

[julpel8]

@baibhavbista After reviewing it, I realized I hadn’t pushed the changes that make it easier to list, edit and listen to the audio.
PS: I vibe write a doc in docs/reference/voice_recordings.md