[Feature Request]: Voice Burst — 1-second compressed voice messages over DM (Codec2 700B)

[Chris7X]

Checklist

• I have used the search function for OPEN ISSUES to see if someone else has already submitted the same feature request.

• I have also used the search function for CLOSED ISSUES to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.

• I will describe the request with as much detail as possible.

• This request contains only one single feature, not a list of multiple (related) features.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

Contact Details

rust-repulsion-jot@duck.com

Feature or improvement you want

Opening this retroactively to the existing PR (#4994 (comment)) to give the feature proper visibility before further review.

What

A push-to-talk button in DM conversations that sends a 1-second Codec2 700B voice clip (~88 bytes) as a single MeshPacket.

Airtime constraints (already implemented)

• 1 second max per burst
• 88 bytes total payload — single packet, well under the 240-byte MeshPacket limit
• 30-second rate limit between sends
• DM-only, no broadcast

Open questions for maintainers

• Is PRIVATE_APP (256) acceptable as a provisional port, or should we request a registered portnum?
• Should this be behind an experimental flag in settings?
• Any preference on Codec2 mode (currently 700B)?

Related PR

#4994 (#4994 (comment))

Why should this be added?

No response

Screenshots / Drawings / Technical details

No response

[shortwavesurfer2009]

What does one second worth of audio get you? Just "yes" or "no" response.

Edit: If one second of audio is 88 bytes, then you should be able to fit two seconds of audio in a single packet. But it doesn't seem like two seconds would get you much more than one second does.

[Chris7X]

What does one second worth of audio get you? Just "yes" or "no" response.

Edit: If one second of audio is 88 bytes, then you should be able to fit two seconds of audio in a single packet. But it doesn't seem like two seconds would get you much more than one second does.

at 8 kHz mono + Codec2 700B, one second gets you roughly 2-4 words, e.g. "on my way", "confirmed", "need help", "aiuto", "ricevuto". Think of it as a voice ACK rather than a conversation. For anything longer, text is the right tool on LoRa anyway.
The 1-second cap is intentional mesh etiquette: single packet, no fragmentation, and with the 30s rate limit you're looking at ~88 bytes every 30 seconds worst case. Negligible on LongFast.
If there's concern about shared channels, the experimental flag idea from the feature request could gate it further.
Also just pushed a minor fix: renamed a misleading log line (broadcasted → sent to $destNodeId) to stay consistent with the DM-only claim.

[ccchdro]

I think that if you have the ability to record, check, and store short audio messages before sending them, it would be an interesting feature, otherwise it's quite difficult to send just one second.

[Chris7X]

I think that if you have the ability to record, check, and store short audio messages before sending them, it would be an interesting feature, otherwise it's quite difficult to send just one second.

I agree with you and that's a fair point; right now it sends immediately on release, which keeps the MVP scope tight. But a record preview send flow would definitely improve usability, especially with the 1s limit. Since the audio is already saved to disk after recording most of the pieces are already in place for a next step.