Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: AES67 Stream Monitor – An app to monitor audio over IP streams (aes67.app)
84 points by phlhar on June 20, 2021 | hide | past | favorite | 23 comments



Rad, it's MIT-licensed open source!

https://github.com/philhartung/aes67-monitor


Very nice! Can you link some resources regarding how to implement AES67? What kind of latencies are you able to achieve?


FWIW, there's a resources page with a number of links that match your inquiry: https://aes67.app/resources

Unfortunately the standard itself you have to buy. It's 50 USD for non-AES-members.

https://www.aes.org/publications/standards/


A draft of the standard that is as far as I know pretty much complete can be found online on the AES website: https://www.aes.org/standards/comments/drafts/aes67-r-171107...


Yes, that's the reason I was asking :( A number of projects implement it, but I'm not an AES member and didn't feel like spending the 50USD for the official specs. I was hoping someone had made a writeup of the overall protocol.


RTP PCM packets timed to a Precision Time Protocol clock.

As most (all?) PC audio devices don't support clock drifting the audio clock to the PTP clock, this application will either resample fractionally or click now and then. So not AES67 in the true sense.


Ahh that answers one of the questions I had when I was thinking about implementing something like this myself, in that none of the audio APIs I know of (WASAPI and ASIO) would give you any chance of syncing your clock with external sources, thus leaving you at the mercy of clicks. Thanks for clearing that up!


Somewhat related trying to find software that can record whatever source I am sending to my speakers, like virtual audio driver. Any ideas ?


ffmpeg does this (and a thousand other things). For Linux and PulseAudio:

  ffmpeg -f pulse -i alsa_output.pci-0000_00_1f.3.analog-stereo.monitor -c:a libopus -b:a 128k capture.opus
Virtual streams are also supported natively by PulseAudio, so you can do some simple mixing of inputs/outputs, in which case you'd specify a different -i value above.

Sidenote shoutout to PulseAudio. It's really come a long way and things just work nowadays, including high bitrate Bluetooth codecs. I haven't had the need to try something else like Pipewire.


Pipewire has got virtual sinks ootb now.


voicemeeter for windows is really good, highly recommend.


This is very cool. I am curious if the maintainers could sync up with the folks that wrote Ampache [1] so people could use the two of them together, for those that stream their catalog locally using aes67.

[1] - https://github.com/ampache/ampache


In similar category but for playing music together, check out Jamulus and Ninjam.

https://jamulus.io/

https://cockos.com/ninjam/


Sorry, but what’s AES67?


Audio over IP - you see it being used with (for example) theatre setups between a processor and powered speakers that take it as an input.

You can (if you are sufficiently well-heeled) use it for home theatre with e.g. a JBL Synthesis 55 and Genelec or Meriden digital speakers.

(Unfortunately, everything in the AV space is fucked up by the copyright cartel, so processors aren't allowed to send anything beyond 24 bit/48 kHz outside their core processing path.)


I never expected to see JBL Synthesis mentioned on HN by anybody else... Are the Synthesis preamp/processors sending out digital audio now? When I was consulting for them the processors exclusively sent analog, usually over XLR, even for Atmos. But the SDEC EQ stage used 96kHz internally, then could send digital audio to the amp over Blu link.

I still use the SDEC EQ and Blu link for audio distribution in my house.


Yeah, the 55s have added AES/Dante output with the caveat it has to be downsampled because HDCP. That said, 24 bit/48 kHz to the speaker is into placebo territory.


a protocol for audio over IP


This is LAN audio streaming right? Like the kind of thing you'd use at a venue. Not internet radio.


Yes, AES67 (like Dante) is geared towards low latency over reliable links. Tipically wired ethernet.


venue audio seems to be the main thing, yes. (Some companies seem to push it for automotive audio distribution too, but I have no idea if any car makers actually are going down the "Ethernet everywhere" train that far)


Yeah if you want real security use AES256 instead ...


No, that's not for security, that's for multi-channel 3.1 (256/67=3.x). So you can stream a L+C+R+LFE. More bass for your face with that sub.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: