Closed jintakhan closed 3 years ago
Thanks for the report. It's hard to see what is going on, to be honest, but the timings look really bad.
Note that turning off resynchronisation does not turn off synchronisation -- you can see that Shairport Sync is trying really hard to sync the audio. It merely stops Shairport Sync performing the resynchronisation step of stopping play and trying to start over with the audio stream.
Can you say what version of Shairport Sync you are using please? (Use $ shairport-sync -V
to get the configuration string.)
Alternatively, if you could download the latest version, switch to thedevelopment
branch (see UPDATING.md) and post a log of operation with resynchronisation enabled, and with the log verbosity set to 2, it would be useful.
It doesn't look like any packets or being lost or anything like that.
Would you know what kind of audio I/O the board has please? It is an identifiable chip? For example, the C.H.I.P. has a sunxi-codec
. You can check with alsamixer
.
It would be well worth checking what the "default" alsa audio device is -- perhaps it's not a real hardware device, but rather some kind of transcoder. You can use alsamixer
to identify a real audio output device which you can then set as the output device in the shairport-sync configuration file.
I'm having the exact same issues!
Hi @rockrabbit. If you could give us some diagnostic information, it would be great, such as device, Linux version, Shairport Sync version, information about the sound card — anything like that to help get some idea what environment Shairport Sync is running in, thanks.
Raspberry PI Zero with Pimaroni PHAT DAC
Raspbian GNU/Linux 9.4 (stretch) Linux version 4.14.34+
(Moved to Developer Build after reading your above comment.. issue still persists)
3.2d42-mbedTLS-Avahi-ALSA-sysconfdir:/etc
Advanced Linux Sound Architecture Driver Version k4.14.34+.
0 [sndrpihifiberry]: HifiberryDac - snd_rpi_hifiberry_dac
Great — I have just that configuration, working well. Interpolation is “basic”. WiFi power management is off. Could you run it for a couple of minutes with log verbosity of 2 and post the log from when Shairport Sync starts please? It would be very useful.
Also could you enable statistics? Thanks.
interpolation = "basic"; // aka "stuffing". Default is "basic"
fix wifi module power sleep
sudo nano /etc/modprobe.d/8192cu.conf
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1
Logging Enabled.. where do I find the Log?
● shairport-sync.service - ShairportSync AirTunes receiver
Loaded: loaded (/lib/systemd/system/shairport-sync.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-04-22 13:09:54 EDT; 13min ago
Main PID: 366 (shairport-sync)
CGroup: /system.slice/shairport-sync.service
└─366 /usr/local/bin/shairport-sync
Apr 22 13:22:30 PiZero shairport-sync[366]: Error 11 using send-to to an audio socket: "Resource temporarily unavailable".
Apr 22 13:22:30 PiZero shairport-sync[366]: Resend request level #8 for packet 53086 in range 52740 to 53334.
Apr 22 13:22:30 PiZero shairport-sync[366]: Error 11 using send-to to an audio socket: "Resource temporarily unavailable".
Apr 22 13:22:30 PiZero shairport-sync[366]: Resend request level #5 for packet 53180 in range 52740 to 53335.
Apr 22 13:22:30 PiZero shairport-sync[366]: Error 11 using send-to to an audio socket: "Resource temporarily unavailable".
Apr 22 13:22:30 PiZero shairport-sync[366]: Resend request level #8 for packet 53087 in range 52740 to 53335.
Apr 22 13:22:31 PiZero shairport-sync[366]: Error 11 using send-to to an audio socket: "Resource temporarily unavailable".
Apr 22 13:22:54 PiZero shairport-sync[366]: Time ping turnaround time: 455369 us -- it looks like a timing ping was lost.
Apr 22 13:23:01 PiZero shairport-sync[366]: Time ping turnaround time: 1111745 us -- it looks like a timing ping was lost.
Apr 22 13:23:05 PiZero shairport-sync[366]: Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microsecon
The log is accessible using journalctl. For example $ sudo journalctl -n 600 -f
will list the last 600 lines (-n 600) and will continue to follow ( -f) the output. If you could copy the lines labeled with shairport-sync and paste them in here it would be great.
Super. At a guess, there is a firewall somewhere that is preventing those resend requests going out. Have you enabled a firewall somewhere (e.g. on the Pi itself, on the router, or on the sending device)? What is the sender? Is it iTunes or iOS? Is it coming from a Windows device? Thanks.
MacOS 10.13.5 Beta (17F45c) iTunes 12.7.4.76
No Firewall
This is clearly something to do with Wi-Fi
and I've made no changes of late other than changing my DNS settings from Google (8.8.8.8) to CloudFlare (1.1.1.1)
Cannot see that being the issue?
Apple Airport Extreme 6th generation
No Firewall on the Pi either:
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Seems like it alright. Anything funny about the router? Does it have a WMM setting (would be worth toggling). Just about to go out of coverage for a couple of hours, sorry.
BTW, there is a more straightforward way to turn off power management — put:
/sbin/iw dev wlan0 set power_save off
In /etc/rc.local
.
WMM
WMM (Wi-Fi Multimedia) prioritizes network traffic according to four access categories: voice, video, best effort, and background. Set to: Enabled All 802.11n and 802.11ac access points should have WMM enabled in their default configuration. Disabling WMM can cause issues for the entire network, not just Apple products on the network.
Sorry, getting back on the issue right now. The attached logs were done with the following procedure:
The board is connected by gigabit ethernet; the iPhone via 802.11ac. Sound is outputting to a headphone, set with volume at 30%.
Verbosity is at 2, statistics on. One log's with resync off, the other on. The installation is vanilla Armbian with just shairport-sync installed on top of the default packages.
The shairport-sync version is 2.8.6...which is the latest version via apt.
I'll see how 3.2 RC handles on the board, give me a bit to build and install it. resync-off.log resync-on.log
lo no wireless extensions.
wlx********** IEEE 802.11bgn ESSID:"Karma" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.462 GHz Access Point: **:**:**:**
Bit Rate:72.2 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=94/100 Signal level=61/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
@rockrabbit Really really sorry, the original issue has nothing to do with wifi. Your issue is a completely different one from the original one.
@mikebrady I think I left out the resync on log above, but I don't think it's relevant now that I built the latest stable version.
Built 3.1.7 on Armbian (Debian "jessie") with options without any trouble:
./configure --with-alsa --with-stdout --with-pipe --with-avahi --with-metadata --with-apple-alac --with-convolution --with-systemd --with-ssl=openssl --sysconfdir=/etc
New issue: enabling resynchronization has problem checking latency, resulting in extremely distorted audio.
Disabling resynchronization results in clean output with very little stutter.
Here's the logs. I got impatient and did 1:30 of audio this time from the Mac. Same procedure as before, though. resync-off.log resync-on.log
The sync failure was found with SoX off. It also persists with it on. Config file is as follows:
general =
{
name = "Magi"
interpolation = "default"
statistics = "yes";
resync_threshold = 0;
log_verbosity = 2;
ignore_volume_control = "yes";
};
alsa =
{
output_device = "default";
};
Opted to do a Brand New Install of Stretch et al... right out of the gate.. stuttering... this has to be an issue with my beloved app!
@prodo123, thanks for your logs. There network side of it seems great, but accessing the output device is what's causing all the difficulties.. You are outputting to the "default" sound card. What is it? It must be a hardware device, not an alsa
pseudo device. The alsamixer
command-line application should help you explore what devices there are -- perhaps you could post your results here. On Debian, it's part of the alas-utils
package.
Hi @rockrabbit -- your problem is really nothing like the OP's. Perhaps you could open a new issue.
@mikebrady The board's very weird.
alsamixer shows only the codec (sun4i-codec) and a bunch of pseudo devices that I don't know what's going on.
amixer gives a little more information, but still no luck:
Simple mixer control 'Left Mixer Left DAC',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'Power Amplifier',0
Capabilities: volume volume-joined
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 63
Mono: 63 [100%] [0.00dB]
Simple mixer control 'Power Amplifier DAC',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Power Amplifier Mixer',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Power Amplifier Mute',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Right Mixer Left DAC',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'Right Mixer Right DAC',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
hwinfo can't find an audio card at all:
cpu:
CPU
CPU
keyboard:
/dev/ttyS0 serial console
network interface:
lo Loopback network interface
eth0 Ethernet network interface
bond0 Ethernet network interface
disk:
/dev/ram2 Disk
/dev/ram0 Disk
/dev/ram3 Disk
/dev/ram1 Disk
/dev/mmcblk0 Disk
partition:
/dev/mmcblk0p1 Partition
hub:
Linux 4.14.18-sunxi ohci_hcd Generic Platform OHCI controller
Linux 4.14.18-sunxi ehci_hcd EHCI Host Controller
Linux 4.14.18-sunxi ohci_hcd Generic Platform OHCI controller
Linux 4.14.18-sunxi ehci_hcd EHCI Host Controller
Linux 4.14.18-sunxi musb-hcd MUSB HDRC host driver
memory:
Main Memory
unknown:
PS/2 Controller
inxi shows sun4i-codec again:
System: Host: magi Kernel: 4.14.18-sunxi armv7l (32 bit) Console: tty 0 Distro: Debian GNU/Linux 8
Machine: No /sys/class/dmi, using dmidecode: no machine data available
CPU: Dual core ARMv7 rev 4 (v7l) (-MCP-) (ARM)
Clock Speeds: 1: 960 MHz 2: 960 MHz
Graphics: Card: Failed to Detect Video Card!
Display Server: N/A driver: N/A tty size: 238x74 Advanced Data: N/A for root out of X
Audio: Card sun4i-codec driver: sun4i-codec Sound: ALSA v: k4.14.18-sunxi
Network: Card: Failed to Detect Network Card!
Partition: ID-1: / size: 15G used: 1.1G (8%) fs: ext4 dev: /dev/mmcblk0p1
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 89 Uptime: 14 min Memory: 69.8/1000.1MB Init: systemd runlevel: 5
Client: Shell (bash) inxi: 2.1.28
Thanks. Could you post the output of $ aplay -l
and also $ aplay -L
please? The audio card looks like the same as is on the C.H.I.P., which works with Shairport Sync.
@mikebrady here you go:
magi@magi:/home/magi# sudo aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
magi@magi:/home/magi# sudo aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=sun4icodec
sun4i-codec,
Default Audio Device
sysdefault:CARD=sun4icodec
sun4i-codec,
Default Audio Device
dmix:CARD=sun4icodec,DEV=0
sun4i-codec,
Direct sample mixing device
dsnoop:CARD=sun4icodec,DEV=0
sun4i-codec,
Direct sample snooping device
hw:CARD=sun4icodec,DEV=0
sun4i-codec,
Direct hardware device without any conversions
plughw:CARD=sun4icodec,DEV=0
sun4i-codec,
Hardware device with all software conversions
magi@magi:/home/magi#
Thanks. Could you try changing the alsa
output device and mixer control name in /etc/shairport-sync.conf
to the following please:
// These are parameters for the "alsa" audio back end, the only back end that supports synchronised audio.
alsa =
{
output_device = "hw:0"; // the name of the alsa output device. Use "alsamixer" or "aplay" to find out the names of devices, mixers, etc.
mixer_control_name = "Power Amplifier"; // the name of the mixer to use to adjust output volume. If not specified, volume in adjusted in software.
// ... all other alsa setting are default.
};
This is what works in the C.H.I.P. It would be interesting to see how it goes in your system. I must say I'm worried that the system clock on your device might be somehow running a good bit slower or faster than nominal, but let's see how this goes -- it's easy to do.
(I'm off line for another hour of so...)
@mikebrady Unfortunately no luck. Same broken pipe errors. It also seems to completely break volume controls. (take it easy!)
Apr 23 16:46:36 localhost shairport-sync[2205]: convolution max length 8192
Apr 23 16:46:36 localhost shairport-sync[2205]: convolution gain is 0.000000
Apr 23 16:46:36 localhost shairport-sync[2205]: loudness is 0.
Apr 23 16:46:36 localhost shairport-sync[2205]: loudness reference level is -20.000000
Apr 23 16:46:36 localhost shairport-sync[2205]: disable resend requests is off.
Apr 23 16:46:36 localhost shairport-sync[2205]: diagnostic_drop_packet_fraction is 0.000000. A value of 0.0 means no packets will be dropped deliberately.
Apr 23 16:46:36 localhost shairport-sync[2205]: avahi: service '05ECA2FDDFA9@Magi' group is not yet committed.
Apr 23 16:46:36 localhost shairport-sync[2205]: avahi: request to add "_raop._tcp" service without metadata
Apr 23 16:46:36 localhost shairport-sync[2205]: avahi: service '05ECA2FDDFA9@Magi' group is registering.
Apr 23 16:46:37 localhost shairport-sync[2205]: avahi: service '05ECA2FDDFA9@Magi' successfully added.
Apr 23 16:46:43 localhost shairport-sync[2205]: New RTSP connection from 192.168.1.13:65490 to self at 192.168.1.10:5000 on conversation thread 1.
Apr 23 16:46:43 localhost shairport-sync[2205]: RTSP conversation thread 1 terminated.
Apr 23 16:46:57 localhost shairport-sync[2205]: New RTSP connection from 192.168.1.13:65495 to self at 192.168.1.10:5000 on conversation thread 2.
Apr 23 16:46:57 localhost shairport-sync[2205]: Connection 2: ANNOUNCE
Apr 23 16:46:57 localhost shairport-sync[2205]: Play connection from user agent "iTunes/12.7.4 (Macintosh; OS X 10.13.5) hwp/t8002 (dt:1)" on RTSP conversation thread 2.
Apr 23 16:46:57 localhost shairport-sync[2205]: Connection 2: SETUP
Apr 23 16:46:57 localhost shairport-sync[2205]: Active-Remote string seen: "1195624653".
Apr 23 16:46:57 localhost shairport-sync[2205]: DACP-ID string seen: "DC604B89835A9B8F".
Apr 23 16:46:57 localhost shairport-sync[2205]: SETUP connection from 192.168.1.13 to self at 192.168.1.10 on RTSP conversation thread 2.
Apr 23 16:46:57 localhost shairport-sync[2205]: Connection 2: RECORD
Apr 23 16:46:57 localhost shairport-sync[2205]: pbeg
Apr 23 16:46:57 localhost shairport-sync[2205]: Hammerton Decoder used on encrypted audio.
Apr 23 16:46:57 localhost shairport-sync[2205]: sync error in milliseconds, net correction in ppm, corrections in ppm, total packets, missing packets, late packets, too late packets, resend requests, min DAC queue size, min buffer occupancy, max buffer occupancy
Apr 23 16:46:57 localhost shairport-sync[2205]: pffr
Apr 23 16:46:57 localhost shairport-sync[2205]: PCM handle name = 'hw:0'
Apr 23 16:46:57 localhost shairport-sync[2205]: alsa device parameters:
Apr 23 16:46:57 localhost shairport-sync[2205]: access type = MMAP_INTERLEAVED
Apr 23 16:46:57 localhost shairport-sync[2205]: format = 'S16_LE' (Signed 16 bit Little Endian)
Apr 23 16:46:57 localhost shairport-sync[2205]: subformat = 'STD' (Standard)
Apr 23 16:46:57 localhost shairport-sync[2205]: number of channels = 2
Apr 23 16:46:57 localhost shairport-sync[2205]: number of significant bits = 16
Apr 23 16:46:57 localhost shairport-sync[2205]: rate = 44100 frames per second (precisely).
Apr 23 16:46:57 localhost shairport-sync[2205]: precise (rational) rate = 0.000 frames per second (i.e. 0/1088784512).
Apr 23 16:46:57 localhost shairport-sync[2205]: period_time = 5804 us (>).
Apr 23 16:46:57 localhost shairport-sync[2205]: period_size = 256 frames (precisely).
Apr 23 16:46:57 localhost shairport-sync[2205]: buffer_time = 2972154 us (>).
Apr 23 16:46:57 localhost shairport-sync[2205]: buffer_size = 131072 frames (>).
Apr 23 16:46:57 localhost shairport-sync[2205]: periods_per_buffer = 512 (precisely).
Apr 23 16:46:59 localhost shairport-sync[2205]: prsm
Apr 23 16:46:59 localhost shairport-sync[2205]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 16:46:59 localhost shairport-sync[2205]: Delay error -32 when checking running latency.
Apr 23 16:47:00 localhost shairport-sync[2205]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 16:47:00 localhost shairport-sync[2205]: Delay error -32 when checking running latency.
Apr 23 16:47:00 localhost shairport-sync[2205]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 16:47:00 localhost shairport-sync[2205]: Delay error -32 when checking running latency.
Apr 23 16:47:00 localhost shairport-sync[2205]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 16:47:00 localhost shairport-sync[2205]: Delay error -32 when checking running latency.
Apr 23 16:47:00 localhost shairport-sync[2205]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 16:47:00 localhost shairport-sync[2205]: Delay error -32 when checking running latency.
Thanks. This is very mysterious, and is beginning to sound like some kind of configuration or driver problem. One thing that might be worth trying is to turn off MMAP access: in the alsa
section of the configuration file, set the use_mmap_if_available
to "no"
. Remember to uncomment the line and restart. It's worth a try, but it is unnecessary on the C.H.I.P., so it's hard to be confident about it.
@rockrabbit, let's move your issue to #689.
@mikebrady No difference without MMAP:
Apr 23 19:45:35 localhost shairport-sync[1279]: New RTSP connection from 192.168.1.13:54101 to self at 192.168.1.10:5000 on conversation thread 1.
Apr 23 19:45:35 localhost shairport-sync[1279]: RTSP conversation thread 1 terminated.
Apr 23 19:45:35 localhost rsyslogd-2007: action 'action 17' suspended, next retry is Mon Apr 23 19:46:35 2018 [try http://www.rsyslog.com/e/2007 ]
Apr 23 19:45:46 localhost shairport-sync[1279]: New RTSP connection from 192.168.1.13:54103 to self at 192.168.1.10:5000 on conversation thread 2.
Apr 23 19:45:46 localhost shairport-sync[1279]: Connection 2: ANNOUNCE
Apr 23 19:45:46 localhost shairport-sync[1279]: Play connection from user agent "iTunes/12.7.4 (Macintosh; OS X 10.13.5) hwp/t8002 (dt:1)" on RTSP conversation thread 2.
Apr 23 19:45:46 localhost shairport-sync[1279]: Connection 2: SETUP
Apr 23 19:45:46 localhost shairport-sync[1279]: Active-Remote string seen: "825120066".
Apr 23 19:45:46 localhost shairport-sync[1279]: DACP-ID string seen: "DC604B89835A9B8F".
Apr 23 19:45:46 localhost shairport-sync[1279]: SETUP connection from 192.168.1.13 to self at 192.168.1.10 on RTSP conversation thread 2.
Apr 23 19:45:46 localhost shairport-sync[1279]: Connection 2: RECORD
Apr 23 19:45:46 localhost shairport-sync[1279]: pbeg
Apr 23 19:45:46 localhost shairport-sync[1279]: Hammerton Decoder used on encrypted audio.
Apr 23 19:45:46 localhost shairport-sync[1279]: Sync packet received before we got a timing packet back.
Apr 23 19:45:46 localhost shairport-sync[1279]: sync error in milliseconds, net correction in ppm, corrections in ppm, total packets, missing packets, late packets, too late packets, resend requests, min DAC queue size, min buffer occupancy, max buffer occupancy
Apr 23 19:45:47 localhost shairport-sync[1279]: pffr
Apr 23 19:45:48 localhost shairport-sync[1279]: PCM handle name = 'default'
Apr 23 19:45:48 localhost shairport-sync[1279]: alsa device parameters:
Apr 23 19:45:48 localhost shairport-sync[1279]: access type = RW_INTERLEAVED
Apr 23 19:45:48 localhost shairport-sync[1279]: format = 'S16_LE' (Signed 16 bit Little Endian)
Apr 23 19:45:48 localhost shairport-sync[1279]: subformat = 'STD' (Standard)
Apr 23 19:45:48 localhost shairport-sync[1279]: number of channels = 2
Apr 23 19:45:48 localhost shairport-sync[1279]: number of significant bits = 16
Apr 23 19:45:48 localhost shairport-sync[1279]: rate = 44100 frames per second (precisely).
Apr 23 19:45:48 localhost shairport-sync[1279]: precise (rational) rate = 0.000 frames per second (i.e. 0/1088784512).
Apr 23 19:45:48 localhost shairport-sync[1279]: period_time = 5804 us (>).
Apr 23 19:45:48 localhost shairport-sync[1279]: period_size = 256 frames (precisely).
Apr 23 19:45:48 localhost shairport-sync[1279]: buffer_time = 2972154 us (>).
Apr 23 19:45:48 localhost shairport-sync[1279]: buffer_size = 131072 frames (>).
Apr 23 19:45:48 localhost shairport-sync[1279]: periods_per_buffer = 512 (precisely).
Apr 23 19:45:49 localhost shairport-sync[1279]: prsm
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #3 for packet 17832 in range 17663 to 17925.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #3 for packet 17833 in range 17663 to 17926.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #3 for packet 17834 in range 17663 to 17927.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #3 for packet 17835 in range 17664 to 17928.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #4 for packet 17826 in range 17704 to 17950.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #4 for packet 17827 in range 17704 to 17951.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #4 for packet 17828 in range 17704 to 17952.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #5 for packet 17829 in range 17720 to 17984.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #5 for packet 17830 in range 17721 to 17985.
Apr 23 19:45:49 localhost shairport-sync[1279]: Resend request level #5 for packet 17831 in range 17722 to 17986.
Apr 23 19:45:49 localhost shairport-sync[1279]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 19:45:49 localhost shairport-sync[1279]: Delay error -32 when checking running latency.
Apr 23 19:45:49 localhost shairport-sync[1279]: Error -32 in delay(): "Broken pipe". Delay reported is 0 frames.
Apr 23 19:45:49 localhost shairport-sync[1279]: Delay error -32 when checking running latency.
and so on with the broken pipe...
Let me build a different version and see if it shows the same behavior.
Thanks -- it was a forlorn hope anyway...
3.2 RC1 behaved the same way so rebuilt and reverted back to 3.1.7.
I looked at the build options that the Debian repo had; the version was:
2.8.6-OpenSSL-Avahi-ALSA-pulse-dummy-stdout-pipe-soxr-metadata-sysconfdir:/etc
and so I changed the build options for 3.1.7 to match (plus extras):
./configure --with-alsa --with-pa --with-soxr --with-stdout --with-pipe --with-avahi --with-metadata --with-apple-alac --with-convolution --with-systemd --with-ssl=openssl --sysconfdir=/etc
Same problem. Just curious, what's the dummy option (has it been deprecated?)?
Thanks. The dummy option just drops the packets of audio -- they are passed to it in a named function and it does nothing with them...
Is there any reason to be suspicious of the Linux system? I see various messages about ARMbian on the net, but it's hard to see if they are current or relevant.
Hmm…I don’t know much about Armbian other than that it doesn’t use much resources. Usually it’s worked okay, even though Armbian development for my board has stopped.
There’s two kernels, Ubuntu desktop and Debian mainline. The Debian distro doesn’t have a GUI and uses less resources. Do you think I should try the Ubuntu distro, or even just plain Ubuntu?
On Apr 23, 2018, at 8:56 PM, Mike Brady notifications@github.com wrote:
Is there any reason to be suspicious of the Linux system? I see various messages about ARMbian on the net, but it's hard to see if they are current or relevant.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mikebrady/shairport-sync/issues/686#issuecomment-383549348, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-8pmjnk5FRxbSVJ_DWQjoWezLfIut_ks5trcFjgaJpZM4TaHfx.
I honestly don't know, I'm afraid. On the face of it, I'd be inclined to go for the one using fewer resources. The only thing is that maybe the Ubuntu one has a different set of drivers or settings that might make a difference. Is it a big problem to change over? But I'm afraid I'm out of my comfort zone here.
Not a problem at all, but I’ll need some time getting it set up.
On Apr 23, 2018, at 9:05 PM, Mike Brady notifications@github.com wrote:
I honestly don't know, I'm afraid. On the face of it, I'd be inclined to go for the one using fewer resources. The only thing is that maybe the Ubuntu one has a different set of drivers or settings that might make a difference. Is it a big problem to change over? But I'm afraid I'm out of my comfort zone here.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mikebrady/shairport-sync/issues/686#issuecomment-383551534, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-8pkr6pyUum6DHapG8n3Ioqfk1IrwDks5trcODgaJpZM4TaHfx.
Take you time :)
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.
Hi,
I've set up shairport-sync on my pcDuino3 nano running Armbian. It's so far installed and able to receive audio, but it has issues with resynchronization that keeps it stuttering and crackling. I've looked into #99 which has the same errors in the log (Lost sync with source for 4 consecutive packets...) and also concluded that resynchronization was causing the issue. The OP says shairplay-sync works flawlessly with his Mac and iPhone, but it's the opposite for me.
Switching resynchronization off (resync_threshold = 0) temporarily fixes the problem, but then the crackling gets worse as the sync error accumulates. You can see this in the iPhone async log in the attachments.
It's also of note that this is much, much worse when streaming from the iPhone than from the Mac.
The source files are ALAC in 16 bit 44.1 kHz. The pcDuino is connected via gigabit ethernet (it's been tested to do around 600 Mbps, i.e. bandwidth is not the issue) and outputs to the 3.5mm output. As it's configured, shairport-sync uses less than 10% of the CPU.
I'll repost with the logs in verbosity=2 after a bit more playing around.
log-async-iPhone.log log-async.log log-sync.log shairport-sync.conf.log