fm-rds-tx/aoiprxkit/README.md

aoiprxkit

Standalone Go module for adding professional AoIP receive capabilities step by step.

This package covers the roadmap up to Phase 4 with a Go-native target architecture:

1. AES67 RX-lite
2. static SDP loading + optional SAP listener
3. stream discovery by SAP/SDP session name
4. live browser metering over HTTP/WebSocket
5. NMOS IS-04 / IS-05 client scaffolding
6. SRT WAN ingest via native transport adapter + framed PCM profile

Included components

Core RTP / AES67-lite receiver

• IPv4 multicast RTP join
• static config or config derived from SDP
• L24 decoding
• small jitter / reorder buffer
• PCM frame callback
• runtime counters

SDP support

• minimal parser for:
  • c=
  • m=audio
  • a=rtpmap
  • a=ptime
• conversion helper from parsed SDP to receiver config

SAP listener

• optional listener for SAP announcements
• default SAP group/port support
• application/sdp extraction
• callback with parsed session details

NMOS scaffolding

• lightweight Query API client
• lightweight Connection API client
• helpers for receiver-side staged activation payloads

SRT WAN bridge (reworked)

• no ffmpeg.exe dependency in the default package path
• generic stream receiver for framed PCM
• SRT receiver abstraction with injectable transport opener
• default build ships a clear stub for the transport layer
• intended production path: wire a pure-Go SRT transport (for example a gosrt opener) in the target repo

Framed WAN audio profile

The package now assumes a deliberately narrow WAN ingest profile:

• transport: SRT
• payload framing: custom framed stream defined in stream_proto.go
• codec today: PCM S32LE
• codec reserved for later: Opus

This keeps the stack deterministic and avoids generic container / demux complexity.

Deliberate non-goals

• no full AES67 compliance claim
• no PTP discipline
• no full SAP session cache
• no bundled gosrt implementation in this zip
• no ST 2110-30 sender/receiver implementation
• no NMOS Node/Registry server implementation

Why it is built like this

The goal is not to overbuild a broadcast plant in one step. The goal is to provide a repo-addable module that gives a realistic progression:

• start with known multicast audio
• add discovery
• add control-plane interoperability
• add WAN ingest without external EXE dependencies as the default design target

Suggested integration order

1. integrate the core receiver into your existing audio input abstraction
2. allow config-by-SDP
3. enable optional SAP auto-discovery
4. add NMOS registry/query support
5. wire a native SRT opener in your target repo

Added in this build

• StreamFinder for exact matching by SDP s= session name
• LiveMeter for per-channel RMS / Peak / Latest values
• MeterServer with /, /healthz, /api/meter and /ws/live