SigmaStar SSC30KQ /play_audio streaming POST / low-latency talkback support.

[Den9Levchenko]

Hello OpenIPC/Majestic team,

I’m using an OpenIPC camera with the following hardware/firmware:

SoC: ssc30kq / SigmaStar Infinity6E family
Sensor: IMX335
Flash: 16 MB NOR
Firmware: 2.6.05.21-ultimate
Build: openipc-ssc30kq

Audio input works correctly over RTSP/WebRTC. I can receive camera microphone audio together with video.

Audio output also works electrically and through Majestic when using /play_audio with a pre-recorded PCM file. The camera has AUDIO_OUT, connected to a PAM8403 amplifier and speaker.

Example working command:

ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" -filter:a "volume=0.95" -ac 1 -ar 8000 -f s16le test.pcm

curl -u root:PASSWORD
-H "Content-Type: application/octet-stream"
--data-binary "@test.pcm"
http://CAMERA_IP/play_audio

Majestic logs show that playback is accepted and sent to SigmaStar AO:

Audio playback: 78KB
[MI_AO_IMPL_SendFrame:2716] Strat pcm out success!!!

AO is initialized at boot:

client [PID] connected, module:ao
[_MI_AO_Init:1248] Init Ao Gain.
Output: 8kHz, 8dB

So the basic output path works:

/play_audio → Majestic → SigmaStar MI_AO → AUDIO_OUT → amplifier → speaker

The problem is that /play_audio appears to behave as a file/clip upload endpoint. It works when the full PCM file is uploaded, but it does not work as a live streaming endpoint for microphone talkback.

Tests attempted:

curl --data-binary @test.pcm http://CAMERA_IP/play_audio
Works.
Python requests.post(..., data=generator) streaming 8 kHz mono s16le PCM from laptop microphone
Does not play during streaming.
Stopping the Python streaming request with Ctrl+C
Still does not play anything afterward.
go2rtc WebRTC two-way audio
Browser microphone reaches go2rtc, but the OpenIPC RTSP probe only shows camera-side receive media:
video, recvonly, H265
audio, recvonly, OPUS/48000/2

There is no RTSP/ONVIF audio backchannel advertised, so go2rtc has no native return audio path to the camera speaker.

I also checked the camera filesystem. The MI_AO kernel/device side exists:

/dev/mi_ao
/proc/mi_modules/mi_ao/mi_ao0
/lib/modules/4.9.84/sigmastar/mi_ao.ko

But there is no separate user-space libmi_ao.so or CLI AO player available. Majestic appears to have the MI_AO userspace functions linked internally. strings /usr/bin/majestic shows symbols like:

/play_audio
MI_AO_SetPubAttr
MI_AO_Enable
MI_AO_EnableChn
MI_AO_SendFrame
MI_AO_SetVolume
MI_AO_SetMute
Request

Could Majestic support low-latency streaming talkback on SigmaStar SSC30KQ / Infinity6E?

Possible implementation ideas:

Make /play_audio support streaming/chunked HTTP POST, where incoming PCM frames are sent immediately to MI_AO_SendFrame instead of waiting for a complete uploaded body.
Add a separate endpoint, for example:
/play_audio_stream

that accepts continuous raw PCM:

8000 Hz
mono
signed 16-bit little-endian PCM

and feeds frames directly into MI_AO.

Optionally support WebSocket or UDP PCM input for lower latency:
/ws_audio_out
udp://camera:PORT

Expected use case:

Browser/laptop microphone
→ 8 kHz mono s16le PCM
→ Majestic streaming audio input endpoint
→ SigmaStar MI_AO
→ camera AUDIO_OUT
→ external amplifier/speaker

This would allow true two-way audio/talkback on SigmaStar OpenIPC cameras that already have working AUDIO_OUT hardware but do not expose an RTSP/ONVIF audio backchannel.

Thanks!

[widgetii]

Hi @Den9Levchenko — thanks for the very thorough write-up. Your diagnosis of /play_audio is correct, and the talkback feature you want already exists in current majestic; it just isn't reachable through /play_audio. A few points:

1. /play_audio is a clip-upload endpoint by design, not a streaming one.
It accepts a complete PCM body, hands it to the SigmaStar audio output, and closes the connection. There is also an upper bound on body size on the SigmaStar path, so even a long chunked POST would be silently truncated. Repurposing it for live talkback would be the wrong transport anyway — HTTP request/response can't give you the framing, ordering and jitter handling that two-way audio needs.

2. Two-way talkback is available as an RTSP audio back-channel (ONVIF Profile T) in recent majestic builds.
When enabled, the SDP for the main RTSP stream gains a second m=audio … sendonly section with rtpmap:0 PCMU/8000 and a control URL …/audio-backchannel. A Profile-T-aware client (Hikvision/Dahua NVRs, go2rtc, ONVIF Device Manager) SETUPs that track over RTSP-interleaved TCP and the camera plays the inbound PCMU stream out of AUDIO_OUT. SSC30KQ is supported because the back-channel sink is the same MI_AO_SendFrame path you already verified.

It is off by default. Enable it in /etc/majestic.yaml:

audio:
  outputEnabled: true
  jitterBufferMs: 80      # optional; 0 (default) is passthrough, fine on LAN
rtsp:
  backchannel: true

Restart majestic, re-DESCRIBE the stream, and you should see the second m=audio section with a=sendonly and a=control:audio-backchannel. If you don't, the majestic shipped in your firmware (2.6.05.21-ultimate, a 2026-05-21 build) is older than this feature — the back-channel landed on 2026-05-24, so you'll need an OpenIPC nightly built after the firmware repo picks up that majestic update. The simplest check on the camera: strings /usr/bin/majestic | grep -i backchannel — if you see audio-backchannel, the feature is present in your binary.

3. go2rtc is the right browser-side bridge.
Once the back-channel is advertised, add the camera as a plain rtsp: source in go2rtc. go2rtc detects the back-channel automatically and transcodes browser-mic Opus down to PCMU/8000 for you. Browser → go2rtc → RTSP back-channel → SSC30KQ speaker is the validated end-to-end path.

4. Caveats worth knowing before you wire up the amplifier:

• No AEC. The PAM8403 → speaker output will be picked up by the camera mic. Plan for physical isolation, or accept the echo for one-way push-to-talk.
• PCMU only on the wire. Other browser-side codecs get transcoded by go2rtc.
• TCP-interleaved transport only. Drive the back-channel through RTSP, not as a raw udp:// URL.
• WebRTC inbound audio (browser mic straight into the camera's WebRTC peer connection) is not implemented; go2rtc + back-channel is the supported answer today.

Please reopen / follow up if you bump the firmware and still don't see the second m=audio section in the SDP.

[Den9Levchenko]

@widgetii, thanks for useful response. Have updated the firmware with latest nightly build *.27 it adds needed functionality. Issue is resolved