mikebrady / shairport-sync

AirPlay and AirPlay 2 audio player
Other
7.26k stars 574 forks source link

Stuttering and crackling issues with streaming from macOS and iOS #686

Closed jintakhan closed 3 years ago

jintakhan commented 6 years ago

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

mikebrady commented 6 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.

mikebrady commented 6 years ago

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.

mikebrady commented 6 years ago

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.

rockrabbit commented 6 years ago

I'm having the exact same issues!

mikebrady commented 6 years ago

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.

rockrabbit commented 6 years ago

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

mikebrady commented 6 years ago

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.

mikebrady commented 6 years ago

Also could you enable statistics? Thanks.

rockrabbit commented 6 years ago

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?

rockrabbit commented 6 years ago
● 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
mikebrady commented 6 years ago

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.

rockrabbit commented 6 years ago

Log Capture.txt

mikebrady commented 6 years ago

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.

rockrabbit commented 6 years ago

MacOS 10.13.5 Beta (17F45c) iTunes 12.7.4.76

No Firewall

This is clearly something to do with Wi-Fi

rockrabbit commented 6 years ago

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

rockrabbit commented 6 years ago

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   
mikebrady commented 6 years ago

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.

rockrabbit commented 6 years ago

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.

jintakhan commented 6 years ago

Sorry, getting back on the issue right now. The attached logs were done with the following procedure:

  1. Restart shairport-sync.service via systemctl
  2. Connect iPhone to shairport-sync (pcDuino3 nano)
  3. Play a song (2:46) until it skips to the next song.

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

rockrabbit commented 6 years ago
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
jintakhan commented 6 years ago

@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";
};
rockrabbit commented 6 years ago

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!

mikebrady commented 6 years ago

@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.

mikebrady commented 6 years ago

Hi @rockrabbit -- your problem is really nothing like the OP's. Perhaps you could open a new issue.

jintakhan commented 6 years ago

@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.

screen shot 2018-04-23 at 3 24 33 pm

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 
mikebrady commented 6 years ago

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.

jintakhan commented 6 years ago

@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# 
mikebrady commented 6 years ago

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.

mikebrady commented 6 years ago

(I'm off line for another hour of so...)

jintakhan commented 6 years ago

@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.
mikebrady commented 6 years ago

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.

mikebrady commented 6 years ago

@rockrabbit, let's move your issue to #689.

jintakhan commented 6 years ago

@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.

mikebrady commented 6 years ago

Thanks -- it was a forlorn hope anyway...

jintakhan commented 6 years ago

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?)?

mikebrady commented 6 years ago

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...

mikebrady commented 6 years ago

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.

jintakhan commented 6 years ago

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.

mikebrady commented 6 years ago

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.

jintakhan commented 6 years ago

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.

mikebrady commented 6 years ago

Take you time :)

github-actions[bot] commented 3 years ago

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.