iPhone X no audio output [WiFi router issue -- resolved]

[malep]

Hi

First up thanks for all the awesome work on this!

I've just pulled/make/installed the current version and got the daemon up and running all apple devices see the airplay target but an interesting problem.

iPhone X running iOS 11.2.5 (current production build) connects but no audio

I tested with: iPhone 7 running iOS 11.2.5 - works fine iPad pro 9.7 running iOS 11.2.5 - works fine Macbook Pro 13" Touch Bar (2016) running macOS 10.13.3 - works fine

It therefore looks like a iPhone X issue

Looking at syslog there don't appear to be any errors, but I'm running at the default logging level. Happy to provide logs at higher level if useful.

[mikebrady]

Thanks for the kind words and the report. I’m not aware of any issues with iPhone X, to be honest. If you could turn on log verbosity to 1 and enable statistics (there’s some suggestions in the CONTRIBUTING page) then we might be able to see what’s happening.

[malep]

I ran shairport-sync from the cli with -v at which point I got audio from the iphone x - however...

I then re-ran as service ($ sudo service shairport-sync start) and silence... stopped the service and did $ sudo shairport-sync -v -d tailed the log file and got this:

Feb 02 07:10:15 raspberrypi shairport-sync[1445]: New RTSP connection from [fe80::862:7267:ed2c:90e4]:61298 to self at [fd59:d85b:64fa:1:a39d:da0:e00e:fcd]:5000 on conversation thread 11.
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Play connection from user agent "AirPlay/356.19" on RTSP conversation thread 11.
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Active-Remote string seen: "3760843060".
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: DACP-ID string seen: "F1246EBE8F2A4CA8".
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Set up play connection from fe80::862:7267:ed2c:90e4 to self at fd59:d85b:64fa:1:a39d:da0:e00e:fcd on RTSP conversation thread 11.
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Output frame bytes is 4.
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Output bit depth is 16.
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Dithering will be enabled because the output volume is being altered in software
Feb 02 07:10:15 raspberrypi shairport-sync[1445]: Set initial volume to -3.148149.
Feb 02 07:10:16 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:16 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:16 raspberrypi shairport-sync[1445]: Hammerton Decoder used on encrypted audio.
Feb 02 07:10:17 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:18 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:19 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:20 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:20 raspberrypi shairport-sync[1445]: Aliasing of buffer index -- reset.
Feb 02 07:10:21 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:22 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:23 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:24 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:24 raspberrypi shairport-sync[1445]: Aliasing of buffer index -- reset.
Feb 02 07:10:25 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:26 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:27 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:28 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:28 raspberrypi shairport-sync[1445]: Aliasing of buffer index -- reset.
Feb 02 07:10:29 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:30 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:31 raspberrypi shairport-sync[1445]: Sync packet received before we got a timing packet back.
Feb 02 07:10:32 raspberrypi shairport-sync[1445]: Player thread exit on RTSP conversation thread 11.
Feb 02 07:10:32 raspberrypi shairport-sync[1445]: RTSP conversation thread 11 terminated.

Looking at previous issues it seems like a network problem but for a brief moment it seemed to be working...

Any suggestions?

[malep]

Thought I'd quickly reboot and run $ shairport-sync -v on the cli. Audio output is there and console output is below (will try daemon next...):

pi@raspberrypi:~ $ shairport-sync -v
alsa output device name is "default".
Version: "3.1.7-OpenSSL-Avahi-ALSA-metadata-sysconfdir:/etc"
statistics_requester status is 0.
daemon status is 0.
deamon pid file is "/var/run/shairport-sync/shairport-sync.pid".
rtsp listening port is 5000.
udp base port is 6001.
udp port range is 100.
player name is "Raspberrypi".
backend is "(null)".
on-start action is "(null)".
on-stop action is "(null)".
wait-cmd status is 0.
on-start returns output is 0.
mdns backend "(null)".
stuffing option is "0" (0-basic, 1-soxr).
resync time is 0.050000 seconds.
allow a session to be interrupted: 0.
busy timeout time is 120.
drift tolerance is 0.001995 seconds.
password is "(null)".
ignore_volume_control is 0.
volume_max_db is not set
playback_mode is 0 (0-stereo, 1-mono, 1-reverse_stereo, 2-both_left, 3-both_right).
disable_synchronization is 0.
use_mmap_if_available is 1.
output_rate is 44100.
output_format is 3 (0-unknown, 1-S8, 2-U8, 3-S16, 4-S24, 5-S24_3LE, 6-S24_3BE, 7-S32).
audio backend desired buffer length is 0.150000 seconds.
audio backend latency offset is 0.000000 seconds.
audio backend silence lead-in time is -1.000000 seconds. A value -1.0 means use the default.
volume range in dB (zero means use the range specified by the mixer): 0.
zeroconf regtype is "_raop._tcp".
decoders_supported field is 3.
use_apple_decoder is 0.
alsa_use_playback_switch_for_mute is 0.
no special mdns service interface was requested.
configuration file name "/etc/shairport-sync.conf" resolves to "/etc/shairport-sync.conf".
metadata enabled is 0.
metadata pipename is "(null)".
metadata socket address is "(null)" port 0.
metadata socket packet size is "500".
get-coverart is 0.
loudness is 0.
loudness reference level is -20.000000
Successful Startup
avahi: avahi_register.
avahi: register_service.
avahi: request to add "_raop._tcp" service without metadata
avahi: service 'AF31192A3A11@Raspberrypi' successfully added.
New RTSP connection from 192.168.2.71:61339 to self at 192.168.2.230:5000 on conversation thread 0.
RTSP conversation thread 0 terminated.
New RTSP connection from [fe80::862:7267:ed2c:90e4]:61338 to self at [fe80::8c91:7fe9:2253:26b2]:5000 on conversation thread 1.
Play connection from user agent "AirPlay/356.19" on RTSP conversation thread 1.
Active-Remote string seen: "2299887967".
DACP-ID string seen: "823A734E083D70DB".
Set up play connection from fe80::862:7267:ed2c:90e4 to self at fe80::8c91:7fe9:2253:26b2 on RTSP conversation thread 1.
Output frame bytes is 4.
Output bit depth is 16.
Dithering will be enabled because the output volume is being altered in software
Set initial volume to -18.000000.
Hammerton Decoder used on encrypted audio.
Using negotiated latency of 88200 frames and a static latency correction of 0
Output written using MMAP

[mikebrady]

Very interesting, thanks. Is there a firewall running somewhere, possibly on a router, blocking ports? (There are some suggestions on the TROUBLESHOOTING page.)

[Update] I edited the format of your post slightly for layout, just to make them more readable.

The repeated Sync packet received before we got a timing packet back message is almost invariably caused by blocked ports -- either the timing synchronisation signals originating in the Pi are being blocked on the way to the iPhone X, or else the response coming from the iPhone is being blocked. Given that sync packets are being received by the Pi (which use a similar transport to the timing responses), I imagine that the problem is with packets going to the iPhone rather than coming from it, but that's a guess. The usual problem is a firewall somewhere, but sometimes it's a faulty router.

[malep]

Looks like I may have tracked it down to IGMP snooping on the router (was disabled). Seems to be a semi-common problem based on the IGMP multicast traffic that Airplay uses. Now that I've enabled it everything looks good.

Thanks for your support on this - happy for you to close off!

[mikebrady]

Glad that it’s sorted out. Just to be clear, to solve the problem, you enabled IGMP Snooping?

[Alphakilo]

Wait what. Are your shairport-sync box and your iPhone X different subnets?

[github-actions[bot]]

This issue has been inactive for 60 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.