AES67 monitoring app for Windows, MacOS and Linux

301 views
Skip to first unread message

Philipp Hartung

unread,
Dec 28, 2020, 7:24:19 AM12/28/20
to Audio over IP
Hey everyone,

I just published the first release of my open source AES67 monitoring app I developed over the christmas holidays. Features include:
  • Auto discovery of streams via Session Announcement Protocol and manually adding streams by pasting SDP data (with the option to broadcast manually added SDP via SAP to the network for other devices)
  • Filtering and sorting streams
  • listening to streams by selecting which channels you want to listen to (Stereo and Mono supported)
  • wide format support: 44100Hz, 48000Hz and 96000Hz (and more) if the soundcard supports it, L16 and L24 PCM with up to 8 channels and all packet times according to AES67 spec are supported
  • Settings for Network interface, audio device, buffering for RTP and more
Features that I would like to implement in the future are PTP timestamp and RTP seqnum monitoring and a dBFS and loudness display for streams. You can download a pre-built binary for Windows, MacOS or Linux on https://github.com/philhartung/aes67-monitor/releases/tag/v0.2.0 or check out screenshots, documentation and the sourcecode over at https://github.com/philhartung/aes67-monitor.

Furthermore I released a little command line tool, to make a local soundcard input available in an AES67 network. You can check that out over at https://github.com/philhartung/aes67-sender. One other tool related to AoIP that I released recently is https://github.com/philhartung/aes67-visualization, a command line tool to easily launch ffmpeg audio visualizations (ebur128 loudness graph, volume, histogram, ...) from AES67 SDP files.

One last thing: A while back I postet my AES67 resource article here on this mailing list. The article is a list of open source projects, tools, interesting whitepapers and other resources related to AES67. I added quite a few resources since I postet it on the mailing list back in july, so it’s probably worth a look again. You can check it out over at https://hartung.io/2020/07/aes67-resources/.

Feedback on any of these things is appreciated :)

Greetings,
Philipp

Elliott Balsley

unread,
Jan 16, 2022, 7:25:17 PMJan 16
to Audio over IP
Hi Philipp, one more question:  I'm curious why you pipe from gstreamer instead just using ffmpeg directly.  Do you get better performance that way?  I needed to monitor 4 separate 8-channel RTP streams so I used your code as a starting point and then came up with this command.  FFplay doesn't work with more than 24 channels so I switched to ffmpeg instead.

ffmpeg -hide_banner -loglevel info -protocol_whitelist file,rtp,udp -i dolby1.sdp \
  -protocol_whitelist file,rtp,udp -i dolby2.sdp \
  -protocol_whitelist file,rtp,udp -i dolby3.sdp \
  -protocol_whitelist file,rtp,udp -i dolby4.sdp \
  -filter_complex "[0][1][2][3] amerge=inputs=4, showvolume=t=0:dm=1:ds=log" -f sdl -

Elliott Balsley

unread,
Jan 16, 2022, 7:25:30 PMJan 16
to Audio over IP
Hi Philipp.  Thanks for sharing, this is a great idea.  I often work remotely and it's hard to get AES67 through the VPN to my house.  So for testing and troubleshooting, I'd like to run the visualizer on a headless server through SSH with X11 forwarding.  Do you have any tips to make this work on XQuartz?  The showvolume window opens for a moment and looks correct with 8 channels, but then the whole window turns solid white.

I added some debugging to your code to get the full command, so then I changed the ffplay part to write a WAV file with ffmpeg instead.  That way I could verify that the gstreamer part is working correctly.  The output looks like this with SSH verbose logging:

$ DEBUG=* node main -f dolby.sdp -t showvolume
  filter filter: ffplay -hide_banner -loglevel error -window_title "showvolume" -f lavfi "amovie=/dev/stdin, showvolume=t=0:dm=3 [out0]" +0ms
  filter command: gst-launch-1.0 -q udpsrc address=239.69.83.67 port=6520 ! application/x-rtp, clock-rate=48000, channels=8 ! rtpjitterbuffer ! rtpL24depay ! audioconvert ! wavenc ! fdsink +1ms
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 42670
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 42672
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 1: free: x11, nchannels 3
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 42676
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 3
On Monday, December 28, 2020 at 4:24:19 AM UTC-8 Philipp Hartung wrote:
Reply all
Reply to author
Forward
0 new messages