Last time I had a sorta-working shairport-sync configuration on my Raspberry Pi, but I didn’t have the SOMA Connect hardware actually working, and I had to make a bunch of compromises in order to get things to even try to start up without reimaging to the 32-bit Raspbian operating system. Well, somehow the filesystem got corrupted and the device was refusing to boot, so I figure this is as good a time as any to document how I got things working in a much nicer way. 1. Backing up existing files From my Linux desktop, I created a restore tarball to plop the soma-connect software and its configuration back onto the Pi’s filesystem after a reimage: cd /media/fluffy/rootfs tar czvf ~/soma-restore-overlay.tar.gz \ var/soma-connect \ etc/soma-connect-crontab.conf \ etc/rsyslog.d/soma-connect.conf \ usr/lib/systemd/system/soma-connect.service \ usr/lib/soma-connect 2. Imaging the Pi OS Using the Raspberry Pi Imager I prepared an SD card with Raspberry Pi 3, making sure to select the 32-bit OS this time, and configured it with ssh and audio. Then I mounted rootfs and then applied my overlay again: cd /media/fluffy/rootfs tar xzvf ~/soma-restore-overlay.tar.gz 3. Booted the Pi and made some configuration changes After the first few boots finished (presumably with a multi-stage post-install provisioning thing that had to do some stuff), I had my desktop up. I opened a terminal and verified that `/usr/lib/soma-connect/soma-connect` works (apparently 32-bit Raspbian actually has all of the required libraries already, go figure!). I then ran `sudo raspi-config` to make the following configuration changes: 1. Under system > audio, selected “Headphones” 2. Under system > boot, selected “Console text console” without autologin Out of an abundance of caution I also disabled pulseaudio (even though there’s no reason it should be starting up at all now): sudo apt remove pipewire pulseaudio 4. Enabled the SOMA Connect services sudo systemctl daemon-reload sudo systemctl enable soma-connect 5. Configured shairport-sync: /etc/shairport-sync.conf general = { name = "bedroom"; } alsa = { output_device = "hw:Headphones"; } 6. Rebooted the Pi, ensured that no GUI started at launch and that pulseaudio wasn’t running, shut it down, then moved it back to my bedroom speakers And now music works again! I still can’t get the SOMA Connect to work (this time it’s not even appearing in HomeKit for some reason?) but at least I Tried™.

Last time I had a sorta-working shairport-sync configuration on my Raspberry Pi, but I didn’t have the SOMA Connect hardware actually working, and I had to make a bunch of compromises in order to get things to even try to start up without reimaging to the 32-bit Raspbian operating system. Well, somehow the filesystem got corrupted and the device was refusing to boot, so I figure this is as good a time as any to document how I got things working in a much nicer way. 1. Backing up existing files From my Linux desktop, I created a restore tarball to plop the soma-connect software and its configuration back onto the Pi’s filesystem after a reimage: cd /media/fluffy/rootfs tar czvf ~/soma-restore-overlay.tar.gz \ var/soma-connect \ etc/soma-connect-crontab.conf \ etc/rsyslog.d/soma-connect.conf \ usr/lib/systemd/system/soma-connect.service \ usr/lib/soma-connect 2. Imaging the Pi OS Using the Raspberry Pi Imager I prepared an SD card with Raspberry Pi 3, making sure to select the 32-bit OS this time, and configured it with ssh and audio. Then I mounted rootfs and then applied my overlay again: cd /media/fluffy/rootfs tar xzvf ~/soma-restore-overlay.tar.gz 3. Booted the Pi and made some configuration changes After the first few boots finished (presumably with a multi-stage post-install provisioning thing that had to do some stuff), I had my desktop up. I opened a terminal and verified that `/usr/lib/soma-connect/soma-connect` works (apparently 32-bit Raspbian actually has all of the required libraries already, go figure!). I then ran `sudo raspi-config` to make the following configuration changes: 1. Under system > audio, selected “Headphones” 2. Under system > boot, selected “Console text console” without autologin Out of an abundance of caution I also disabled pulseaudio (even though there’s no reason it should be starting up at all now): sudo apt remove pipewire pulseaudio 4. Enabled the SOMA Connect services sudo systemctl daemon-reload sudo systemctl enable soma-connect 5. Configured shairport-sync: /etc/shairport-sync.conf general = { name = "bedroom"; } alsa = { output_device = "hw:Headphones"; } 6. Rebooted the Pi, ensured that no GUI started at launch and that pulseaudio wasn’t running, shut it down, then moved it back to my bedroom speakers And now music works again! I still can’t get the SOMA Connect to work (this time it’s not even appearing in HomeKit for some reason?) but at least I Tried™.

Okay, it turns out that there was a lot of hidden magic on the SOMA Connect image that was infeasible to try to migrate/clone over myself, both due to dependencies on how the old-ass Raspbian image is setup in terms of networking, and a whole bunch of random/hidden scripts that do who-knows-what. So I decided to take a different approach, and modify the SOMA Connect image instead. 1. I downloaded SOMA Connect, specifically version 2.3.1 and flashed it to my RPi’s SD card 2. I grew the partition to actually fill the card: sudo growpart /dev/mmcblk0 2 sudo e2fsck -f /dev/mmcblk0p2 sudo resize2fs /dev/mmcblk0p2 3. Plugged a monitor and keyboard into the Pi, and booted it up 4. Used the SOMA Connect app to set up wifi on the Pi (and also added it to HomeKit while I had the app open) 5. Logged into the Pi using the provided username/password (`pi`/`SOMAConnect1`) 6. Enabled ssh with `sudo systemctl enable ssh && sudo systemctl start ssh` (ideally there’s some way of doing this or its equivalent to the mounted SD card) 7. Used `sudo raspi-config` to set the audio to “Headphones”, and then used `alsamixer` and `alsactl store` to save the default volume settings that I like 8. `sudo apt update && sudo apt dist-upgrade` to update all of the system packages, and rebooted 9. Discovered that the version of shairport-sync in the configured Debian repository is both super old and super broken, but also that the soma-connect image had all the devtools installed, so I opted to just build it locally, using the official build instructions. Here’s the steps I took, though, for completeness' sake: sudo apt install --no-install-recommends build-essential git autoconf automake libtool \ libpopt-dev libconfig-dev libasound2-dev avahi-daemon libavahi-client-dev libssl-dev libsoxr-dev \ libplist-dev libsodium-dev libavutil-dev libavcodec-dev libavformat-dev uuid-dev libgcrypt-dev xxd wget https://github.com/mikebrady/shairport-sync/archive/refs/tags/4.3.7.tar.gz tar xzvf 4.3.7.tar.gz cd shairport-sync-4.3.7 autoreconf -fi ./configure --sysconfdir=/etc --with-alsa \ --with-soxr --with-avahi --with-ssl=openssl --with-systemd --with-airplay-2 make sudo make install sudo tee /etc/shairport-sync.conf << EOF general = { name = "bedroom"; } alsa = { output_device = "hw:Headphones"; } EOF sudo systemctl daemon-reload sudo systemctl enable shairport-sync sudo systemctl start shairport-sync 10. Discovered that shairport-sync also needs nqptp to be running, so I just ran its (very simple) install instructions, followed with: sudo systemctl daemon-reload sudo systemctl enable nqptp sudo systemctl start nqptp sudo systemctl start shairport-sync 11. Things seemed to be _actually_ working now, so out of an abundance of caution I shut down the Pi and made a new image of the SD card for safekeeping so I wouldn’t have to go through all this crap all over again: sudo dd if=/dev/mmcblk0 of=soma-connect-2.3.1-shairport.img bs=1M For steps 3-6 I’d really like to be able to just mount the SD card on my Linux machine and then edit some config file directly, but I’m not actually sure how `systemctl enable` works. It would certainly make things easier if I didn’t have to do that and could just start out being able to ssh into it. But this is such a minor annoyance compared to the rest of all this that there’s not _too_ much point in trying to optimize that bit away. Anyway now things seem to be working: pi@soma-connect:~ $ ps auxwww | grep shair shairpo+ 693 10.8 1.8 155816 17732 ? SLsl 06:17 0:02 /usr/local/bin/shairport-sync --log-to-syslog pi 1234 0.0 0.0 7344 480 pts/0 S+ 06:17 0:00 grep --color=auto shair pi@soma-connect:~ $ ps auxwww | grep soma-con avahi 374 1.2 0.3 6028 3020 ? Ss 06:17 0:00 avahi-daemon: running [soma-connect.local] pi 1236 0.0 0.0 7476 528 pts/0 S+ 06:17 0:00 grep --color=auto soma-con pi@soma-connect:~ $ and notably, I can both listen to music in my bedroom _and_ (theoretically) control my blinds from HomeKit automations, so, yay.

Last time I had a sorta-working shairport-sync configuration on my Raspberry Pi, but I didn’t have the SOMA Connect hardware actually working, and I had to make a bunch of compromises in order to get things to even try to start up without reimaging to the 32-bit Raspbian operating system. Well, somehow the filesystem got corrupted and the device was refusing to boot, so I figure this is as good a time as any to document how I got things working in a much nicer way. 1. Backing up existing files From my Linux desktop, I created a restore tarball to plop the soma-connect software and its configuration back onto the Pi’s filesystem after a reimage: cd /media/fluffy/rootfs tar czvf ~/soma-restore-overlay.tar.gz \ var/soma-connect \ etc/soma-connect-crontab.conf \ etc/rsyslog.d/soma-connect.conf \ usr/lib/systemd/system/soma-connect.service \ usr/lib/soma-connect 2. Imaging the Pi OS Using the Raspberry Pi Imager I prepared an SD card with Raspberry Pi 3, making sure to select the 32-bit OS this time, and configured it with ssh and audio. Then I mounted rootfs and then applied my overlay again: cd /media/fluffy/rootfs tar xzvf ~/soma-restore-overlay.tar.gz 3. Booted the Pi and made some configuration changes After the first few boots finished (presumably with a multi-stage post-install provisioning thing that had to do some stuff), I had my desktop up. I opened a terminal and verified that `/usr/lib/soma-connect/soma-connect` works (apparently 32-bit Raspbian actually has all of the required libraries already, go figure!). I then ran `sudo raspi-config` to make the following configuration changes: 1. Under system > audio, selected “Headphones” 2. Under system > boot, selected “Console text console” without autologin Out of an abundance of caution I also disabled pulseaudio (even though there’s no reason it should be starting up at all now): sudo apt remove pipewire pulseaudio 4. Enabled the SOMA Connect services sudo systemctl daemon-reload sudo systemctl enable soma-connect 5. Configured shairport-sync: /etc/shairport-sync.conf general = { name = "bedroom"; } alsa = { output_device = "hw:Headphones"; } 6. Rebooted the Pi, ensured that no GUI started at launch and that pulseaudio wasn’t running, shut it down, then moved it back to my bedroom speakers And now music works again! I still can’t get the SOMA Connect to work (this time it’s not even appearing in HomeKit for some reason?) but at least I Tried™.

<div class="body" id="preamble"> <p>I’ve reorganized my bedroom and as part of it I decided to finally address the ongoing issues with my audio setup in there. I have an old AirPort Express which I was using as an AirPlay receiver so that I could play music and podcasts and such on the (rather nice) hi-fi speakers, but it’s been super unreliable as of late, and even when it does remain connected, it generates random popping noises on the speakers — not great when I’m trying to sleep!</p><p>So anyway I was looking up various aftermarket AirPlay receivers, and most of them are pretty expensive, but then I realized that there’s probably a way of receiving AirPlay on a Raspberry Pi, and <a href="https://github.com/mikebrady/shairport-sync">yes, there is</a>, and then just as I was about to look for used Raspberry Pis to install this on, I remembered I already have a Raspberry Pi, in my bedroom, in the very same nightstand I would be putting a new one in: because I have <a href="https://www.somasmarthome.com/">SOMA</a>’s older smart shades which use a rebadged Raspberry Pi as their Bluetooth-to-HomeKit bridge.</p><p>And the SOMA Connect image is just running Linux (specifically Rasbian 10) and some proprietary software.</p> </div><div id="more"> <h3 id="12650_h3_1_First-attempt"><a class="toc_link" href="https://beesbuzz.biz/blog/12650-SOMA-Connect-shairport-sync#12650_h3_1_First-attempt"></a>First attempt</h3><p>Originally I just rooted the SOMA Connect (which isn’t hard to do, SOMA even provides <a href="https://support.somasmarthome.com/hc/en-us/articles/360014397380-SOMA-Connect-Raspberry-Pi-username-and-password">instructions</a>) and tried building shairport-sync for it. But even though the Pi came with a 16GB SD card, the SOMA Connect image limits it to only 2GB for some reason. So, I expanded the partition to 16GB and also cleaned up a bunch of stuff, and went through the shairport build and install process. Which went okay, but I couldn’t get iTunes to connect to it.</p><p>So I tried rebooting… and the device wouldn’t come back up.</p><p>Part of the build instructions involved doing an <code>apt update &amp;&amp; apt upgrade</code> which would normally be okay but this is actually something I’d run into before with this device and hadn’t thought about: the latest Rasbian kernel causes SOMA Connect to fail to boot. Oops.</p><p>So I took a different tactic.</p><h3 id="12650_h3_2_The-correct-approach"><a class="toc_link" href="https://beesbuzz.biz/blog/12650-SOMA-Connect-shairport-sync#12650_h3_2_The-correct-approach"></a>The correct(?) approach</h3><p>First, I used the <a href="https://www.raspberrypi.com/software/">Raspberry Pi Imager</a> to build a stock image for the SOMA Connect (Pi 3, enable ssh + audio), and then flashed it onto the SD.</p><p>Then I installed shairport-sync from <code>apt</code> (as it’s a current-enough version), and… iTunes was unable to play to it, although it could connect.</p><p>I did a lot of debugging steps (including using <code>mpg123</code> to play audio directly from the command line, which worked fine) until I finally figured out that the problem is that stock Rasbian installs pulseaudio, which in turn restricts the speakers to only be accessible by the current GUI user, which a headless daemon is not. There is a <a href="https://github.com/mikebrady/shairport-sync/issues/1596">lengthy GitHub thread</a> that eventually discusses the issues and potential fixes for it, but in my case I realized there’s no reason to run pulseaudio on this device, so I just <code>apt remove pulseaudio</code> and then suddenly shairport worked just fine. Yay!</p><p>Actually getting the SOMA Connect software running was a bit more challenging.</p><p>Before I reimaged the device I made a full backup of the filesystem, although this isn’t strictly necessary as if you have a Linux device you should be able to mount <a href="https://support.somasmarthome.com/hc/en-us/articles/360035521234-Install-SOMA-Connect-software">the disk image</a> and extract data from it.</p><p>SOMA does have a Debian package repository for their stuff, but it’s not open to the public; clearly it’s only meant to be accessed from their image building process.</p><p>There’s also a <a href="https://github.com/hoobs-org/soma-connect">HOOBS soma-connect repository</a> but the package they provide is both very old and very broken, and didn’t actually help with getting anything to work.</p><p>So anyway, I copied the following files off of the SOMA Connect image into their appropriate places:</p> <ul> <li><code>/var/soma-connect/</code> (empty directly normally, although I preserved my previous settings)</li> <li><code>/etc/soma-connect-crontab.conf</code> (which turns out to be empty and is probably just a stray file)</li> <li><code>/etc/rsyslog.d/soma-connect.conf</code></li> <li><code>/usr/lib/systemd/system/soma-connect.service</code></li> <li><code>/usr/lib/soma-connect/</code> (which contains the actual binaries for some reason)</li> </ul> <p>Then I tried running <code>/usr/lib/soma-connect/soma-connect</code> and got an error about an unresolved library. But <code>ldd</code> said that it was not a dynamic binary.</p><p>After a bit more poking I came to realize that the binary is 32-bit, and I’d installed 64-bit Rasbian. So my choices were to either downgrade to 32-bit rasbian, or to get multiarch running. Fortunately, multiarch is pretty easy to do on ARM:</p> <ol> <li><code>sudo dpkg --add-architecture armhf</code></li> <li><code>sudo apt update &amp;&amp; sudo apt upgrade</code></li> <li><p>Install all of the missing libraries with an <code>:armhf</code> designation. Unfortunately, <code>ldd</code> still doesn’t work across architectures<sup id="r_e12650_fn1"><a href="https://beesbuzz.biz/blog/12650-SOMA-Connect-shairport-sync#d_e12650_fn1" rel="footnote">1</a></sup>, so I kept running it and got errors for missing libraries. Here is what I ended up installing; I don’t know if all of these were necessary:</p><figure class="blockcode"><pre><span class="line"><span class="line-content">sudo apt install gcc-12-base:armhf ifplugd:armhf libatomic1:armhf \</span></span> <span class="line"><span class="line-content"> libc++-dev:armhf libc++1:armhf libc6:armhf libstdc++6:armhf</span></span> </pre></figure></li> </ol> <p>Anyway, now the <code>soma-connect</code> binary runs, and the iOS app is able to connect to it over Bluetooth. So activating the service just takes:</p><figure class="blockcode"><pre><span class="line"><span class="line-content">sudo systemctl enable soma-connect</span></span> <span class="line"><span class="line-content">sudo systemctl start soma-connect</span></span> </pre></figure><p>The only thing I haven’t managed to get working is… HomeKit being able to actually talk to the curtains, which is, y'know, the entire point to having the SOMA Connect in the first place. But that’s something that’s always been a bit unreliable anyway (and the worst part of the SOMA experience), and probably just requires resetting all of the related HomeKit connections and so on. Watching the soma-connect logs might also be educational in this regard.</p><p>For now I’m fine with just using the SOMA app to maintain the curtain schedules anyway, which is what I’d been doing most of the time (the HomeKit thing is just nice to have sometimes).</p><p>Anyway, the obvious next thing to do is to run DOOM.</p> </div><aside id="footnotes"><ol><li id="d_e12650_fn1"><p>I have since learned that <code>readelf -d</code> works in lieu of <code>ldd</code> though. <a href="https://beesbuzz.biz/blog/12650-SOMA-Connect-shairport-sync#r_e12650_fn1" rev="footnote">↩</a></p></li></ol></aside>

<div class="body" id="preamble"> <p>Just some random stuff about the state of media management in my life.</p> </div><div id="more"> <h3 id="16343_h3_1_Home-security"><a class="toc_link" href="https://beesbuzz.biz/blog/16343-Tech-wrangling#16343_h3_1_Home-security"></a>Home security</h3><p>Okay so. I have around 1TB of photos, because I used to shoot RAW on my DSLR.</p><p>Apple really, really wants me to start using iCloud for a bunch of stuff to work right; Spotlight no longer indexes local libraries stored on external drives, for example, and to get HomeKit security that can do proper facial recognition you need to have an iCloud photo library.</p><p>Handling sync between a phone and an offline Photos library has also gotten super stupid.</p><p>I currently have the 50GB iCloud plan (which costs $1/month and provides single-camera home security). Mostly I just use the app that works directly with my cameras (since it does local recording and basic event detection) but I also have it set up to work with HomeKit Secure Video, which may or may not actually be doing anything useful. It’s super hard to tell.</p><p>Anyway. Back in the day I used <a href="https://en.wikipedia.org/wiki/Aperture_%28software%29">Aperture</a> for photo library management, but then was super grumpy when I was forced to switch to iPhoto. For a while I made it suck less by using iPhoto Library Manager by <a href="https://fatcatsoftware.com/">Fat Cat Software</a>, which cost something like $30, but then Photos broke that, and so I just made do with a single gigantic Photos library and kind of stopped caring about categorizing and posting things for the most part.</p><p>Recently I learned that Fat Cat has a new bit of software, <a href="https://www.fatcatsoftware.com/powerphotos/">PowerPhotos</a>, which actually works with Photos and is pretty decent? And it also had decent upgrade pricing from iPLM, so I’ve upgraded there.</p><p>Right now my photo management strategy is to take photos on my iPhone and have them sync to iCloud, and then to use PowerPhotos to copy the stuff I care about into my offline library, and just get more aggressive about deleting stuff from iCloud. That seems to be working okay, but I’ve only just started with that so who knows how sustainable that’ll be.</p><p>In the meantime, I haven’t had enough stuff happen with my cameras to know if HomeKit Security is actually doing anything useful. It certainly hasn’t been notifying me of the few events that have happened (package deliveries, one visit from Charlie, etc.) and I’m just like. Super confused about how it’s supposed to work.</p><h3 id="16343_h3_2_Music"><a class="toc_link" href="https://beesbuzz.biz/blog/16343-Tech-wrangling#16343_h3_2_Music"></a>Music</h3><p>I like, but don’t love, Apple’s Music.app (née iTunes, not to be confused with Apple Music, the streaming service). I have a rather large library of music that I own (not rent), and I like to listen to stuff in the mode of:</p> <ol> <li>Choose a random album</li> <li>Play it all the way through</li> <li>Repeat</li> </ol> <p>This is easy to do in Music.app, and I also use a smart playlist to avoid playing albums I’ve heard recently (although that happens so rarely now due to the enormity of my collection), as well as a few things that I’m usually not in the mood for. I also appreciate that I can migrate what I’m listening to anywhere in my house since I have AirPlay-enabled devices everywhere, and I can even simulcast if I want.</p><p>I used to use a smart playlist to also sync a subset of this over to my iPhone for listening on the go, but that’s gotten super obnoxious to manage for a bunch of reasons. I tried using <a href="https://support.apple.com/en-us/108935">iTunes Match</a> for this but it never worked reliably, either. It’s also super annoying to get my playcounts synchronized over to <a href="https://last.fm/user/plaidfluff">Last.fm</a>.</p><p>I do keep a backup of my music library on my <a href="https://plex.tv/">Plex</a> server, and recently I started using PlexAmp and its “album radio” function. Which is Fine. But it kind of sucks for the in-home experience, because of a few things:</p> <ul> <li>If something interrupts the music or you want to temporarily play something else there’s no way to go back where you were before</li> <li>It has no native AirPlay support, and using external AirPlay with it is kind of a mess</li> <li>The UI is fine for phones, terrible for desktops</li> </ul> <p>But what I’ve settled on for now is using PlexAmp for shuffling my music when I’m driving or on the bus or whatever, and using good ol' Music.app at home. It seems Fine™.</p> </div>

YouTube video by The Chalkeaters