What’s new
The pub’s audio system now sends six discrete channels of audio to a small Raspberry Pi in the AV rack — one stereo pair for pub Spotify, one for the wall-stereo aux jack (the one a phone or laptop plugs into), and one for the wall XLR jacks used during DJ nights. The Pi listens to all three at once, picks whichever is loudest, identifies the song, and posts it to the pub website.
The visible change for residents: every song on pub.ihnyc-rc.org/setlist now carries a small icon showing where the audio came from.
| Icon | Source |
|---|---|
| Speaker | Pub Spotify (the default house playlist) |
| Phono jack | Wall stereo aux input (someone plugged in a phone or laptop) |
| Turntable | Wall XLR (DJ night) |
The same logic drives the “Now Playing” footer on the TVs — songs identified during a DJ set now correctly reflect the DJ feed, not whatever Spotify happened to be playing in the background.
Why this matters
Before this week, the Pi was listening to a single mono mixdown of everything in the room. It identified songs fine, but it couldn’t tell who was playing them. A DJ track and a Spotify track looked identical to the system, and the source tag on /setlist/ was blank.
With AES67 live, the room is self-aware:
- When a tender plugs into the wall aux and starts playing something,
/setlist/reflects that within ~10 seconds — and the source icon tells you it came from the aux jack, not the house playlist. - When the DJ takes over, the XLR pair lights up and gets picked. Tracks identified during the set carry the turntable icon.
- When the room goes quiet, all three pairs drop below the silence floor and the “Now Playing” surfaces hide automatically.
It also means that the next time you hear something at the pub and want to know what it was, the setlist will tell you not just the song but the context — Friday’s DJ set or last Tuesday’s chill background Spotify.
What you’ll see, in three places
On /setlist/
The current track at the top of the page (the “Now Playing” hero card) and every row in the history below now carries a small monochrome icon on the left side. Tap a track row and the existing split-button affordance opens it in Spotify (or Apple Music / Tidal / YouTube Music via the caret menu).
On the TV footer
The “Now Playing” slot on the in-venue TV board picks up DJ-night tracks correctly now. No visual change to the footer itself — it’s the same album art + title + artist layout — but the data feeding it is more accurate.
On the landing page
The Setlist nav button at pub.ihnyc-rc.org still shows a live ”▶ Title — Artist” description, and that description now reflects whichever source the system is hearing — so glancing at the landing page from across the room gives you a real read of what’s happening, not just whatever the default playlist would have been.
How it works (the short version)
The pub’s Q-SYS Core (the rack-mounted audio computer that handles every input and output) sends a special multi-channel network audio stream called AES67 onto the AV LAN. AES67 is a vendor-neutral standard — Dante, RAVENNA, Livewire, and Q-SYS can all speak it. The Pi runs an open-source daemon that subscribes to that stream and hands it to the existing song-ID pipeline as a 6-channel audio device.
Every two seconds, the Pi measures the loudness of each stereo pair, picks the loudest non-silent one, and fingerprints it against the Shazam catalog. The fingerprint becomes a {title, artist, source} blob that gets posted to the pub website, stored in Cloudflare D1, and fanned out to the TVs and /setlist/ via Server-Sent Events.
For the technically curious, the full picture is in the Now Playing & Setlist System doc — channel maps, source picker code, PTP clock setup, the works.
Known small thing
Enabling AES67 turned on the Core’s PTP master, which now contests with an existing Dante endpoint for grandmaster status. Every few hours the contest flips, and the Core logs a brief audio clock event that’s audible as a single short click on the program bus. It’s harmless to the song-ID pipeline (the Pi clocks audio reception independently) but we’re going to fix it in a follow-up Q-SYS Designer session by giving the Core a higher PTP priority so it wins the contest consistently. If you hear an isolated click on a quiet song this week, that’s what it is.
Privacy
The pipeline never stores raw audio anywhere. The Pi processes audio entirely in memory — capture, fingerprint, identify, send the title and artist to the website. Only the identification result and the source label leave the AV rack. Since the Pi now receives line-level audio directly from the Q-SYS Core over AES67, it doesn’t pick up room conversation at all (which was a residual concern with the previous USB-microphone-style capture path).
Credits
Built by the resident audio + software working group as part of the I-House Pub site. AES67 transmitter configured in Q-SYS Designer; Pi-side bridge using aes67-linux-daemon + linuxptp. Song identification courtesy of the open-source shazamio client. All of it ties into the existing pub Worker + Cloudflare D1 + Server-Sent Events stack that’s been powering /setlist/ since the song-ID pipeline first went live.
Questions, song requests, or bug reports → grab a tender, or open an issue on the pub-landing repo.
Related
- setlist — current public setlist behavior
- now-playing-system — full technical write-up (channel map, PTP, source picker)
- pi-capture-ops — operational reference for the Pi capture service
- setlist — the
/setlist/page itself