Error in setup request.

[webattitude]

new RTSP connection.
    CSeq: 1.
    Content-Type: application/sdp.
    Content-Length: 573.
    User-Agent: iTunes/4.6 (Macintosh; U; PPC Mac OS X 10.3).
    Client-Instance: XXXXXXXXXXX.
    Apple-Challenge: XXXXXXXXXXXXX.
Play connection from user agent "iTunes/4.6 (Macintosh; U; PPC Mac OS X 10.3)".
Process metadata with type 73736e63, code 736e7561 and length 44.
    Apple-Response: XXXXXXXXXXXXXXXXXXX
    CSeq: 1.
    Audio-Jack-Status: connected; type=analog.
    CSeq: 2.
    Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record.
    User-Agent: iTunes/4.6 (Macintosh; U; PPC Mac OS X 10.3).
    Client-Instance: XXXXXXXXX.
Error in setup request.
    CSeq: 2.
    Audio-Jack-Status: connected; type=analog.

[mikebrady]

Hi Thomas. I think your version of iTunes is too old – it predates the revision of the RAOP protocol in 2010. See #110 for some more information.

[webattitude]

Yet, I was not using itunes, I thin system airplay client is advertising itself as such. I'm on macos el capitan.

[mikebrady]

Thanks Thomas. Normally, AirPlay advertises as itself, so this is somewhat unusual. Could you say what application you're using please?

[webattitude]

no applicaiton, I was just expecting to see shairport-sync device available in macos sound dropdown menu (and sound settings) where it used to be. The error message appears right after restarting shairport-sync. I've just reinstalled the daemon on a new jessie raspbian, because the old one's package system was broken.

[mikebrady]

Very curious. The log extract shows what seems to be iTunes 4.6 on Mac OS 10.3 on a PowerPC based Mac – 2004/5 vintage. Do you have such a machine on your network somewhere?

[webattitude]

nope, but I have module-raop (airtunes) for pulseaudio it may be the source of the log. Yet, the device does not appear any more on my mac.

[webattitude]

seems to work now, at least shairport-sync since I got no sound : pulseaudio/alsa has a kind of a bug with snd_pcm_delay()...

[mikebrady]

Hmm. It's all very strange. If you are sending Shairport Sync's output to default and the default happens to be a pulseaudio virtual device, things may not work out well. Shairport Sync needs a real hardware device to output to.

[webattitude]

The main pb regarding shairport-sync and pulseaudio is that pulseaudio launch afterwards at boot, this apart, it used to work well. Now the other pb, which implies alsa afaik, occurs also on the client raspi which sends via rtp to PA on the shariport one, so both devices are rpi, with either an usb dac or a hifiberry dac.

[mikebrady]

The latency information provided by a pulseaudio virtual device is unsuitable for Shairport Sync. Shairport Sync expects the latency to be exact and immediate – it expects it to be the exact number of samples of audio that are in the output device's buffer at that instant. It seems that pulseaudio doesn't provide that. For example, if pulseaudio reported a latency of, say 6,000 frames, and Shairport Sync added 352 frames, pulseaudio might continue to report a latency of 6,000 instead of 6,352. In other words, it seems that pulseaudio gives a non-real-time estimate of the latency which it updates from time to time. This might be fine for many applications, but unfortunately it is worse than useless for Shairport Sync as it currently uses latency information. Thus, I think it would take considerable re-architecting of Shairport Sync to accommodate pulseaudio – not impossible, but pretty tricky. And I'll be honest – it's not on my to-do list.

[webattitude]

crystal clear, thank you. What pulseaudio team said about that ?

[mikebrady]

I haven't been in contact with the pulseaudio guys. This is just the result of some experimentation and reading the docs.