Airplay is not visible - Waiting for audioblock to start...

Project help balenaSound
1

Hello Balena Community,

I’m testing currently the Balena Sound and i am excited :heart_eyes:.

My setup is a Raspberry Pi 4 4B with a Innomaker Rpi HiFi DAC Hat.
Spotify and Bluetooth works perfect for me and the sound is great!

I have a feed with the balenaSound release, the balenaSound release is 3.6.9, host os is balenaOS 2.83.10+rev1 and the supervisor version is 12.10.1.

My device is connected over vpn, all stats ready up and green :blush:

The services are up and i disabled multiroom option with STANDALONE

I activated the dac card under the device configuration, the sound works fine.
BALENA_HOST_CONFIG_dtoverlay = allo-boss-dac-pcm512x-audio

I customize my Device with the following options:
AUDIO_OUTPUT DAC
BLUETOOTH_DEVICE_NAME Studio
SOUND_DEVICE_NAME Studio
SOUND_DISABLE_BLUETOOTH True
SOUND_MODE STANDALONE
SOUND_SPOTIFY_BITRATE 320
SOUND_SPOTIFY_ENABLE_CACHE ENABLE

Our problem is, we see no the balena airplay device under our iphones 11 max pro or iphone 12. We see only our sonos devices.

In balena dashboard we see only “Waiting for audioblock to start…”

image
image762×238 2.96 KB

The Raspberry is connected over wifi and lan for testing on the same network, in my example 10.10.12.0/24. the iPhones are in the same network.

Im nut sure is this a bug or not, im searching so much in google.

Regrads,
Christian

2

same problem with the older version balenaOS 2.75.0+rev1 :neutral_face:

4

Hi @chris2, balenaSound dev here. Can you try restarting the airplay service and see if that helps? You can do that by clicking the Stop/Play buttons on the lower left portion of the dashboard for your device. Typically airplay waits for the audio service to start before starting, but since you say Spotify is working then it means the audio service has started but airplay seems to be stuck.

6

hi @tmigone. Yes you can see in the screenshot, the airplay service is restarting. Bluetooth and Spotify is working fine and the music are good. Unfortunately, a restart does not help

7

I tested it all again.

Delete all devices and feets, go in balenaHub, click on balenasound, click on “Fork this fleet”.
Add a new device in the balenasound feet, Select device type “Raspberry Pi 4” and balenaOS, latest version and edtion production.

The new device is downloading and installing all services. After this, the device is ready in the balenacloud dashjboard.

I go under “CUSTOM CONFIGURATION VARIABLES”, set the variable “BALENA_HOST_CONFIG_dtoverlay” to “hifiberry-dacplus” (i have here a second dac card Hifiberry DAC2 PRO)
Under device configuration RESIN_HOST_CONFIG_dtparam “audio=on” to “audio=off”.

The same result →

image
image1131×510 22 KB

8

image
image1144×393 17.1 KB

image
image1074×124 6.13 KB

image
image1007×125 13.1 KB

Bluetooth and Spotify works fine

9

I think sharepoint-sync is never starting on the device →

image
image1296×817 53.9 KB

I can start manually sharepoint-sync, i can connect the device, but no sound is coming.

image
image1184×188 4.54 KB

10

hi @tmigone. I tested a little bit more and read in github in the airplay/start.sh and your information.

I can start and play music over AirPlay with the command “shairport-sync --name “test” --output pa”.

image
image790×193 3.14 KB

11

@tmigone you have maybe new?

12

Hi,

At the risk of suggesting a workaround that may have already been fixed elsewhere, or is otherwise completely useless.
I’ve had a little look at Balena Sound (just grabbed the git repo and balena pushed to a local device) and found a workaround that may or may not work.
As I don’t have any Apple products, it’s difficult for me to tell for sure whether this works properly, but at the very least I see the service announced in avahi-discover as opposed to before this change.

The way I understand it, it all boils down to the network_mode: host in docker-compose.yml.
Because airplay uses network_mode: host, it shares the same networking stack as the host, and therefore the check for a default route resolves to your router, rather than a docker network containing sound-supervisor.
Because sound-supervisor is also using network_mode: host, it should be reachable on localhost.

I’ve modified plugins/airplay/start.sh to check whether SOUND_SUPERVISOR is already defined:

if [ -z ${SOUND_SUPERVISOR} ]; then
    SOUND_SUPERVISOR="$(ip route | awk '/default / { print $3 }'):$SOUND_SUPERVISOR_PORT"
fi

And in docker-compose.yml, I’ve added the following to the airplay service:

depends_on:
  - "sound-supervisor"
environment:
  - 'SOUND_SUPERVISOR=localhost'

This will make the airplay service see a valid server (the call to ${SOUND_SUPERVISOR}/ping returns OK) and continue its work, resulting in shairport-sync being started and the service being announced over mDNS (avahi/bonjour).

I would love to hear some opinions on this.

14

@tjvv, sorry for the delayed response. I think you are spot on with the diagnostic here. I put together a PR with the fix and a detailed write up of the issue in here if you are interested: airplay: fix connection bug with airplay by tmigone · Pull Request #508 · balenalabs/balena-sound · GitHub. It seems that my home router does reply to the curl requests it was being sent, that made AirPlay start, misled me into thinking it was working correctly and made my setup unfit to reproduce this issues!

This actually is a long standing issue that I had been unable to figure out for a while now and was giving us headaches, just search the forums for AirPlay or see the amount of tickets this PR closes! As a token of appreciation I’d like to send some balena swag your way, if you are ok with that please contact me via private message with your contact information (Name, Address, Email, T-shirt size). Thanks again!