buzz during track switching [Fixed?]

[mistepien]

On my old iphone I hear annoying buzzing (1 sec lasting, very audible) during switching tracks. In logs I have:

daemon.debug` shairport-sync.5000[2213]: Player: packets out of sequence: expected: 1, got: 46106, with ab_read: 46107 and ab_write: 46301. May 1 10:23:49 shadow daemon.debug shairport-sync.5000[2213]: Resend request level #6 for packet 46130 in range 46118 to 46316.

Shairport version is: 3.2RC5-OpenSSL-Avahi-ALSA-stdout-pipe-soxr-convolution-metadata-sysconfdir:/etc" Sender logs in as "AirPlay/160.10" IOS: 6.1.3

[artenverho]

I have the same issue on an Allwinner a20 device running debian. The distortions are very loud and disturbing. For me does matter from what source I play the tracks

At first I thought it might be related to the apple-alac setting, but reinstalling without this did not help. I eventually reverted back to the latest stable release 3.1.7 which fixed the problem.

[mikebrady]

Thanks for these reports. To clarify, are you using standard settings? Is convolution or anything like that switched on? Are you enabling soxr interpolation? What device and DAC are you using? Are you using a hardware mixer, or is it just software volume control?

And then, if I may ask, exactly what are you doing to cause the problem? For instance, are you using the Music app on an iPhone and just switching track?

Thanks again – sorry for all the questions!

[mikebrady]

One other question, please – are you using Siri or are play sessions being interrupted by telephone calls and then resumed? Or does it happen all the time?

And for @mistepien, can we just check versions of the software sending the audio please. Is it really iOS 6.1.3 and AirPlay/160.10. (For reference, from macOS 10.13.5 and iOS 11.3.1, it's AirPlay/365.53.)

I'm just trying to visualise situations...

[artenverho]

Hi mikebrady,

This is the list of configurations I used when compiling: ./configure --sysconfdir=/etc --with-alsa --with-apple-alac --with-avahi --with-ssl=openssl --with-metadata --with-soxr --with-systemd. Other than that I have soxr interpolation and the apple alas decoder enabled in the .conf file. Shairpoint is running on an olinuxino a20 board (https://www.olimex.com/wiki/A20-OLinuXino-MICRO) running armbian using the onboard audio output. For sending I am using iPhone SE with the latest IOS.

As I said I have already downgraded to 3.1.7 but if you want to I can reinstall RC5 and try to replicate the problem? is there any logs that might give you more insight?

thanks for all your hard work on this! I use it almost every day!

[mikebrady]

Thanks @artenverho. One further question please: are you using a hardware mixer (i.e. have you set a value for the mixer_control_name in the alsa section)?

Also, forgive the silly question, but am I correct in assuming you have not set a value for audio_backend_latency_offset_in_seconds?

[artenverho]

I have not touched both these settings so indeed the volume is adjusted in software. slightly off topic: is there a benefit of adjusting the volume through a mixer rather than in software in terms of sound quality?

Let me know if you need more input.

[mikebrady]

Thanks, yeah, in principle, using a mixer might be slightly better. Separately, using a mixer might remove the buzzing — it would be an interesting experiment, and might narrow down the possible cause of the problem.

[artenverho]

Ok I reinstalled the RC5 version and indeed the buzzing noise occurs again every time I change tracks in the music app on my iPad. Changing the volume adjustment to hardware mixer unfortunately does not solve the problem. It also happens when I seek through a you tube video and stream the audio trough shairport.

[mikebrady]

Many thanks for all that information. Let me do a bit more digging.

[mistepien]

In my case in conf there is: interpolation set to soxr wait_for_completion=yes output_format=S24_3LE output_device=hw:X,X

use_mmap_if_available=no

no hardware mixer, output device is usb->spdif converter and no hardware mixer is available at all.

version 3.1.7 works just fine.

[mikebrady]

Many thanks -- this is a bit of a mystery and might take a little time to replicate and track down...

[mistepien]

Ok this what I got in logs: out.txt

[mikebrady]

Thanks for that information. I notice that there are start and stop scripts, e.g. /usr/local/bin/start-shairport.sh. What would happen if they were not in use? In other words, is it possible that the buzzing is being caused by the start and stop procedures? (TBH, it doesn’t make sense to me, but it might be worth checking...)

[mistepien]

#!/bin/sh
COMMAND=`basename` $0
startfunc() {
    mpc.bin pause 1>/dev/null 2>/dev/null
    logger "shairport-sync play"
}
stopfunc() {
    logger "shairport-sync stop"
}
case $COMMAND in
    start-shairport.sh) startfunc
        ;;
    stop-shairport.sh) stopfunc
        ;;
    *)  true
        ;;  
esac

On 3.1.7 and earlier versions everything is OK.

[mikebrady]

Thanks again.

[mikebrady]

Would it be possible to get a recording of the buzzing please?

[mikebrady]

One change that was made was to replace snd_pcm_drain with snd_pcm_drop when closing the alsa device. It works perfectly, but maybe it doesn't work properly on your device, so, when I get a chance, I'll change it back on a separate new branch of Shairport Sync. (The difference between them is that snd_pcm_drain plays all the audio frames still in the device, whereas snd_pcm_drop is supposed to discard all audio frames immediately. So, it should be better, but maybe it isn't.)

[mikebrady]

I've pushed a new branch called i694 with that change made from using snd_pcm_drop to snd_pcm_drain and a couple of extra debug messages in it. I'd be grateful if you would try it out. You can use the procedure outlined in the UPDATING page, but where is suggests using the command $ git checkout development to switch to the development branch, enter the command $ git checkout i694 instead, to switch to this new branch.

[mistepien]

out.txt

I downloaded this via github website.

There is the same problem.

[mistepien]

Problem is only during manual track switching. When tracks start after others all is ok.

[mikebrady]

Many thanks for your efforts. I don't have an S24_3LE device here. Does your setup allow you to try S32 or S24 or S16? If so, does the buzz persist?

[mikebrady]

Still digging, BTW.

[mikebrady]

Another question, please: The interval between tracks when you manually switch tracks should be about two seconds. Is it possible for you to say whether the buzzing is at the start or the end of that interval? Or does it run for the entire period?

[mikebrady]

I think I'm getting something, using iTunes 10.6.1 on Mac OS X 10.6.8. A very distinct buzz lasting about a quarter of second just before the new track begins. Does that sound like a description of the phenomenon you're experiencing?

[mikebrady]

Does it happen with interpolation set to "basic" rather than "soxr"?

[mikebrady]

I found and fixed another possible cause, a pretty subtle one:

When you start a new play session, a flush is done of the remains of the previous session. After any flush, the first 10 frames (about 80 mS) of the resumed session are discarded, since they often have some frames from before the flush – possibly stuff lying in the network buffer or somewhere. The 10 frames are replaced by a silent frame played 10 times.

However, it was assumed that when the silent frame was passed to the alsa play function, it would not be modified. Mostly that is true in my experience, but occasionally it seems that the silent frame becomes corrupted with noise. After it happens, the next time you cause a flush to occur, the 10 frames of silence become 10 frames of noise. This persists until the play session fully ends because the next play session reinitialises the silent frame.

I've pushed an update with a fix for this on the same i694 branch, and again I'd be very grateful if you would try it out. It was very difficult to cause this problem in the first place, so I'm not certain it's your issue.

[mistepien]

It just works fine now. Thanks a lot!

[mikebrady]

Great. Thanks for your help in tracking it down.

[artenverho]

I tried the i694 branch and it indeed fixes the buzzing! Thanks! I do seem to have problems with stability, exspecially when using YouTube. It seems to crash shairport when I stop playback. It seems to give a segmentation fault (see below). Also I noticed that it does not seem recognize the hardware mixer properly (something about the dB volume scale not recognized).

$ shairport-sync -v
alsa output device name is "default".
note: the hardware mixer specified -- "Master" -- does not have a dB volume scale.
Cannot get the dB range from the volume control "Master"
Version: "3.2d47i694,2-OpenSSL-Avahi-ALSA-soxr-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 "Marantz".
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 "1" (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 1.
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
disable resend requests is off.
diagnostic_drop_packet_fraction is 0.000000. A value of 0.0 means no packets will be dropped deliberately.
avahi: service '0169D78EB23A@Marantz' successfully added.
Error -32 writing 352 samples in play(): "Broken pipe".
Error -32 writing 351 samples in play(): "Broken pipe".
Error 11 using send-to to an audio socket: "Resource temporarily unavailable". Backing off for 0.5 seconds.
Segmentation fault

[mikebrady]

Thanks for the report. It's good that the buzzing thing is gone -- that's progress to be sure. Now, if you could figure out how to reproduce that segmentation fault, it would be great.

That Error 11 message indicates that a resend request was not able to be sent, generally because of a network problem. I'll have a look to see if the segmentation fault is being caused by improper handling of the error message.

The mixer needs to report its attenuation in decibels, otherwise Shairport Sync can't use it.

[Update] I edited your post slightly for layout. I hope that's okay with you.

[mikebrady]

Hello again. Is the segmentation error thing a new behaviour?

[artenverho]

Hi, the segmentation is indeed something new, it also seems to indeed drop some of the audio a bit more. While this did happen earlier sometimes as well it seems more frequent with this build

[mikebrady]

Thanks. I might have done something silly. I’ll check.

[mikebrady]

Hello again. Indeed, it does seem as if there was a fault with Shairport Sync's handling of this kind of error. There is poor programming practice there, and it may be causing the problem. (More generally, the difficulty is that I can't get the error to occur, so can't test how well it's handled.)

Anyhow, I've replaced the poor programming with something more robust, and pushed the update in the development branch. If you'd be kind enough to try it, it would be great.

In your testing, I suggest that you set interpolation to "basic", as the "soxr" setting may cause the processor to be overwhelmed at times. Much better to get the rest of the setup fully debugged before enabling that.

[Update] You should also consider enabling statistics, which will give you an idea of the number of late packets and resend requests. Also, at a log verbosity of 2, you get the average, standard deviation and maximum interval between audio packets, which may give you more of an understanding of what's happening on the network.

[artenverho]

Okey I tested the new build. It seems to be dropping a little less of the audio in YouTube but it is still doing so when starting the video . I will need to do bit more comparing but I think this was a quite a bit better with 3.1.7. Did you reduce the size of the buffer that is made before syncing the audio?

The segmentation issue is stil there but it only happens when soxr interpolation is enabled:

Resend request level #8 for packet 6487 in range 6445 to 6735.
Resend request level #8 for packet 6489 in range 6445 to 6737.
Player: packets out of sequence: expected: 6384, got: 6520, with ab_read: 6521 and ab_write: 6749.
Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds:     9036.7,    63290.5,  2950967.0.
Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds:     7978.7,    12332.6,    66878.0.
Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds:     7979.6,    12373.8,    53164.0.
pfls
pffr
prsm
Connection 1: TEARDOWN
Segmentation fault

[mikebrady]

Thanks for the update. It's interesting that the seg fault is after teardown, so I'll keep looking. The packet reception interval stats are interesting. The mean should be 353/44100 seconds, i.e. 7981.86 microseconds. I notice a very long maximum interval at the start -- nearly three seconds! The rest of the stats look okay.

If you enable statistics, it will give an idea of resend requests, etc.

I didn't reduce the buffer size -- it should be two seconds exactly.

[mikebrady]

If you can get that seg fault to happen on demand, it would be super if you could set the verbosity to 3 and cause the seg fault. It might narrow down where the issue is occurring.

[artenverho]

I can get it on demand (closing the YouTube app while playing a video in ios11). Here is the log:

Control Receiver -- Retransmitted Audio Data Packet 3033 received.
Control Receiver -- Retransmitted Audio Data Packet 3034 received.
Control Receiver -- Retransmitted Audio Data Packet 3003 received.
Control Receiver -- Retransmitted Audio Data Packet 3035 received.
Control Receiver -- Retransmitted Audio Data Packet 3004 received.
Control Receiver -- Retransmitted Audio Data Packet 3036 received.
Control Receiver -- Retransmitted Audio Data Packet 3005 received.
    CSeq: 17.
    DACP-ID: 25CF386BE4EE6180.
    Active-Remote: 1024537396.
    User-Agent: AirPlay/365.53.
RTSP thread 1 received an RTSP Packet of type "OPTIONS":
  Type: "CSeq", content: "17"
  Type: "DACP-ID", content: "25CF386BE4EE6180"
  Type: "Active-Remote", content: "1024537396"
  Type: "User-Agent", content: "AirPlay/365.53"
Connection 1: OPTIONS
RTSP thread 1: RTSP Response:
  Type: "CSeq", content: "17"
  Type: "Server", content: "AirTunes/105.1"
  Type: "Public", content: "ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER"
    CSeq: 18.
    DACP-ID: 25CF386BE4EE6180.
    Active-Remote: 1024537396.
    User-Agent: AirPlay/365.53.
RTSP thread 1 received an RTSP Packet of type "TEARDOWN":
  Type: "CSeq", content: "18"
  Type: "DACP-ID", content: "25CF386BE4EE6180"
  Type: "Active-Remote", content: "1024537396"
  Type: "User-Agent", content: "AirPlay/365.53"
Connection 1: TEARDOWN
TEARDOWN: synchronously terminating the player thread of RTSP conversation thread 1 (2).
Segmentation fault

[mikebrady]

Thanks again.

[mikebrady]

I'm afraid I really don't know what the cause of this problem is, but it's great (for me!) that it seems reproducible. I've added a few debug messages to try to narrow down where the segmentation fault might be occurring, and I've pushed the update in the development branch. Whenever you get a chance, could you repeat that previous crash sequence. Here is what I get:

Connection 1: TEARDOWN
TEARDOWN: synchronously terminating the player thread of RTSP conversation thread 1 (2).
buffer_get_frame exiting due to thread stop request.
Play thread main loop exited.
Requesting output device to stop.
Shutting down audio, control and timing threads
Audio receiver -- Server RTP thread interrupted. terminating.
Control RTP thread interrupted. terminating.
Timing thread interrupted. terminating.
Wait for timer requester to exit.
rtp_timing_sender thread interrupted. terminating.
Closed and terminated timer requester thread.
Timing RTP thread terminated.
timing thread joined
audio thread joined
control thread joined
Freeing audio buffers and decoders.
Player thread exit on RTSP conversation thread 1.
pend
TEARDOWN: successful termination of playing thread of RTSP conversation thread 1.
RTSP thread 1: RTSP Response:
  Type: "CSeq", content: "16"
  Type: "Server", content: "AirTunes/105.1"
  Type: "Connection", content: "close"
RTSP conversation thread 1 -- connection closed.
Synchronously terminate playing thread of RTSP conversation thread 1.
player thread of RTSP conversation 1 is already deleted.
Successful termination of playing thread of RTSP conversation thread 1.
Request termination of RTSP conversation thread 1.
Unlocking play lock on RTSP conversation thread 1.
RTSP conversation thread 1 terminated.

Many thanks again for all your efforts -- it's probably a bit more than you bargained for, I'm afraid.

[mistepien]

Maybe you should use strace and/or gdb? This tip from musicpd.org webside related to MPD. https://www.musicpd.org/doc/user/bugs.html

I filled few bug tickets using this solution and they were very productive for Kellermann (main developer of MPD)

[mikebrady]

Very useful thanks!

[artenverho]

Happy to help! i've run it again:

RTSP thread 1 received an RTSP Packet of type "OPTIONS":
  Type: "CSeq", content: "38"
  Type: "DACP-ID", content: "3F7208F2F6CFE37A"
  Type: "Active-Remote", content: "1943718279"
  Type: "User-Agent", content: "AirPlay/365.53"
Connection 1: OPTIONS
RTSP thread 1: RTSP Response:
  Type: "CSeq", content: "38"
  Type: "Server", content: "AirTunes/105.1"
  Type: "Public", content: "ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER"
Control Receiver -- Retransmitted Audio Data Packet 21560 received.
Control Receiver -- Retransmitted Audio Data Packet 21561 received.
Packet reception interval stats: mean, standard deviation and max for the last 2,500 packets in microseconds:     7978.7,    16317.3,   151124.0.
    CSeq: 39.
    DACP-ID: 3F7208F2F6CFE37A.
    Active-Remote: 1943718279.
    User-Agent: AirPlay/365.53.
RTSP thread 1 received an RTSP Packet of type "TEARDOWN":
  Type: "CSeq", content: "39"
  Type: "DACP-ID", content: "3F7208F2F6CFE37A"
  Type: "Active-Remote", content: "1943718279"
  Type: "User-Agent", content: "AirPlay/365.53"
Connection 1: TEARDOWN
TEARDOWN: synchronously terminating the player thread of RTSP conversation thread 1 (2).
Segmentation fault

[mikebrady]

Thanks. Yikes, that is a pretty definite crash! With your help, let me make a few more changes to see if the "epicentre" can be located!

[mikebrady]

I wonder if you'd be willing to try the approach referred to by @mistepien above, using gdb? It's a slightly tricky request. Here is how it would run (the example is on a Raspberry Pi, in the shairport-sync build directory). The idea is to run the build of shairport-sync under the control of gdb from the build directory rather than the installed version of shairport-sync. The installed version is not running.

$ gdb --args ./shairport-sync -vvv
…
Reading symbols from ./shairport-sync...done.
(gdb) run
... 

At the (gdb) prompt, the run command was given. Then play some audio through it and stop it. In the gdb console, you'll get something a bit like this:

Thread 12 "shairport-sync" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb51482e0 (LWP 27260)]
0x0002bd4c in stop () at audio_alsa.c:920
920   printf( "%c\n", s[0] );
(gdb)

It won't be like that exactly, because what's shown above is code to generate a deliberate seg fault. By typing bt into gdb, one can get the so-called backtrace, which should highlight where the seg fault occurred, a useful clue:

(gdb) bt
#0  0x0002bd4c in stop () at audio_alsa.c:920
#1  0x000256e0 in player_thread_func (arg=0x82400) at player.c:2297
#2  0xb68e0fc4 in start_thread (arg=0xb51482e0) at pthread_create.c:335
#3  0xb6653c68 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

If you could get that, it would be very helpful. There is a slight complication. The application uses a UNIX signal "SIGUSR1" to send notifications between threads, and gdb needs help to interpret them. So you might get something like this:

         0.001365987|Shutting down audio, control and timing threads

Thread 12 "shairport-sync" received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb3dff2e0 (LWP 27309)]
0xb664d370 in __pselect (nfds=16, readfds=0xb3dfe420, writefds=0x0, exceptfds=0x0, timeout=<optimized out>, sigmask=sigmask@entry=0x64cf8 <pselect_sigset>)
    at ../sysdeps/unix/sysv/linux/pselect.c:69
69  ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
(gdb) 

where you can see that it's a SIGUSR1 signal that occurred. Simply enter continue – there might be three or four such SIGUSR1 notifications.

[artenverho]

I tried it but was not able to detect any airplay device on my ios11 devices. I am sure I am probably doing something stupid. Below the readout from gdb:

gdb --args ./shairport-sync -vvv
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./shairport-sync...done.
(gdb) run
Starting program: /root/shairport-sync/shairport-sync -vvv
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction.
0xb6da8e88 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) 

[mistepien]

I think that ss should be started in foreground, not as a daemon.

Dnia 10 maj 2018 o godz. 16:06 artenverho notifications@github.com napisał(a):

I tried it but was not able to detect any airplay device on my ios11 devices. I am sure I am probably doing something stupid. Below the readout from gdb:

gdb --args ./shairport-sync -vvv GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./shairport-sync...done. (gdb) run Starting program: /root/shairport-sync/shairport-sync -vvv [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction. 0xb6da8e88 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mikebrady]

@artenverho, that's great work, with an unexpected outcome – I don't know what it means, but it could be significant. If you could do it again, and enter the bt command into gdb when it happens, it might give us a clue. I guess it might be possible that there is some system-wide issue with your setup, but for the moment, let's assume that there is not – this could be an important clue to a silly oversight in Shairport Sync. Thanks again.

(@mistepien, I'm guessing it's being started in the foreground – do you think differently?)

[artenverho]

Here you go:

gdb --args ./shairport-sync -vvv
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./shairport-sync...done.
(gdb) run
Starting program: /root/shairport-sync/shairport-sync -vvv
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction.
0xb6da8e88 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) bt
#0  0xb6da8e88 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#1  0xb6da6a04 in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#2  0xb6fe23d6 in ?? () from /lib/ld-linux-armhf.so.3
#3  0xbefffe28 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

[mikebrady]

Thanks. I'll have to think about this one -- my guess is that it's an artefact of gdb itself, and not a real issue, as it looks like a problem with initialising a pretty standard library. Maybe others might have an opinion...