ANNOUNCE: AirPlay Bridge = integrate AirPlay devices with LMS (squeeze2raop)

[philippe_44]

After lots of tests and help (especially from epoch, thanks!) here is a new bridge that allows AirPlay devices (speakers and a lot of AV amplifier from Marantz, Denon ...) to be used as if they were regular LMS players. Compared to my other bridges, it brings replaygain, gapless, fading (in/out/cross) and ... what was the most important for me: synchronization with other LMS players.

• It does decode ogg, ogf, ops, mp3, flac, aac, alac, wav, pcm and aif, does the resample and then sends the audio in AirPlay expected format (plain PCM or encoded ALAC).
• It consumes 5~7% of CPU for a raspi 2B per active AirPlay device
• There are versions for Windows, Linux x86 (32 and 64 bits) and ARM, OSX
• It can run on LMS or on another computer on your network (for example you can dedicate a raspi as the bridge and forget about it)
• You need to add firewall rules to let squeeze2raop (-win or -x86 or -x86_64 or -armv6hf) open the ports he needs. They can be set to a base+count or can be left dynamic. In Windows, just set a rule to authorize squeeze2raop-win.exe (in the plugin cache directory)

The stable version is now part of the 3rd party plugin built-in list, so you should find it in the plugins page. If you want to test the development version (there is not always one on-going), just add the following repository

http://downloads.sourceforge.net/project/lms-plugins-philippe44/dev/repo-sf.xml

You need at least to select one helper binary, the bridge will not run otherwise. For Windows users, please install the Microsoft package whose link is provided. In general, prefer the non-static version if possible. For arm devices, the armv6 is for older CPU (PiZero 1st gen and other early Pi with ARM1176 processor)

This plugin *requires* SSL to stream HTTPS directly and pair with AppleTV so make sure it's installed on your LMS server. Not a problem for Windows, OSX, most Linux x86, Raspberry pi, Cubie, Odroid and others that use a Debian-based, but can be problematic with some NAS. I don't have a perfect guide, so please refer to your NAS forum, but most of the recent NAS firmware update include SSL as well, so that might be all that is required.

Other than that, Perl must have SSL support enabled, which again is available in all recent distribution and LMS versions (I think). But in case of problem and for Debian-ish Linux, you can try "sudo apt-get install libio-socket-ssl-perl libnet-ssleay-perl" at any command prompt. Here is as well the link to the original thread http://forums.slimdevices.com/showth...l=1#post631449

Other tips

• For shairport-based players (ShairportW, Kodi) and cheap Chinese knock-off (GGMM and many others) you must enable encryption
• If the player seems to be un-responsive, before de-activating/re-activating the whole plugin, you can try to switch it off/on in LMS
• One of my player takes a lot of time to start playing (>5s and volume changes interrupt playback - itunes gives the same result, so I assume this is a player problem. So be patient if the volume does not comes right after playback. Other players will start and when this one joins the group, it will be in sync
  
• With docker, network must be set to 'host' mode
• HomePod require "Send LMS metadata to player" to be enabled in plugin's settings and for recent iOS, "Allow Speaker and TV Access" shall be set to "Anyone On The Same Network" in device's settings
• Read the User's Guide which is accessible in the Settings

Debug HELP

Folks, if you want help, you must post here the LMS version you're using, the OS and CPU. Then you must take a log of the bridge (go to the plugin's settings in LMS settings, tab advanced, it's self-explanatory).
I won't be able to help and I will not answer dry questions like "it does not work"

Advanced information

The "binary helper" is an independent application that is the *real* bridge. The LMS plugin part does not do much other than offering a UI to edit config files (and has a special role for AppleTV). So you can run that binary helper on *any* computer/Pi on your network, it does not have to run together with LMS. The compromise is that you will have to edit manually the XML config file. A version with detected players can be generated automatically using the -i option, but after that you're on your own. Refer to user guide for more details.

[epoch1970]

sf.net raining on the parade

Booohoohoohoooo... I've removed my dev install and now I get redirection limit exceeded when I try any of the 2 repo urls
(so LMS always wants to restart to finish install and fails and asks again for a restart...)

I messed about with things like "curl http://iweb.dl.sourceforge.net/projects/lms-to-raop/dev/repo-sf.xml" until I landed on the final redirection, in my case "http://freefr.dl.sourceforge.net/project/lms-to-raop/dev/repo-sf.xml" --as of right now. Don't try this URL.
But the problem is that your repo file contains a link to iweb for the zip file...

Sourceforge is in a serious state of flux, shall we say...
Perhaps it's time to revert to manual install instructions?

I'll try again later, perhaps the weather will clear up a little bit. But I thought I'd post in case others encounter an issue with installing.

(BTW, since I can't really live without the plugin, I started my test machine which still has dev-11... I noticed your sox magic does not seem to work with remote library URLs.)

[castalla]

Using version 0.1.0.1 (no idea anymore if it's the stable or dev !!!) - but still getting the sound loss after random time, with restart stream recovering the sound.

[epoch1970]

Something I did to find the "right" value of player audio delay: I created an AIFF file with alternating 2secs L/R tones, for a total length of 60 secs.
I set an SB3 to play only the right channel, [I wanted to do the opposite with the software player but I always got both channels output] I half-unplugged the audio cord on my Airport Express to output the left channel only.
Then I synced the group, played the file in loop and fiddled with the audio delay slider on the software player.
Until you reach the right value to your setup and ears, you'll hear a silence gap and/or both sources at the same time.
To my surprise, the right value for this device was around 400ms (nearly 50ms higher than I thought)
I don't know what you think of the idea but if felt I needed some help in assessing the right audio delay.

EDIT. Since we are knee-deep into psychoacoustics, another remark, but within the same post
I have 1 source to the left of a small room where I am sitting and 1 source on the right, nearby. Speaker systems are *not* the same. Sync is perfect but I can feel the "stage" shifting from left to right (and back) from time to time. Yeah, I know that's scary... I think (not verified) this is related to 10ms player sync adjustment events within LMS. 10ms is the minimum value in the web interface. Is it possible to go lower?
Please disregard if this doesn't make sense.

[epoch1970]

Using version 0.1.0.1 (no idea anymore if it's the stable or dev !!!) - but still getting the sound loss after random time, with restart stream recovering the sound.

I think this is the stable version. Are you using a 1000ms network buffer in the plugin? This is the recommended setting, but if you had installed an earlier dev version this was set by default at 500ms.
At 500ms the player is more reactive to commands, but I've seen drops.

EDIT: The path is: Settings>Advanced>Airplay Bridge,
then [Default parameters] or your_player_name,
look for AirPlay options: Networking buffer (ms)

[castalla]

I think this is the stable version. Are you using a 1000ms network buffer in the plugin? This is the recommended setting, but I you had installed an earlier dev version this was set by default at 500ms.
At 500ms the player is more reactive to commands, but I've seen drops.

EDIT: The path is: Settings>Advanced>Airplay Bridge,
then [Default parameters] or your_player_name,
look for AirPlay options: Networking buffer (ms)

Buffer already at 1000. Just experienced another sound loss ...

[epoch1970]

Buffer already at 1000. Just experienced another sound loss ...

I suppose you're on wifi? How does it fare wrt to ping regularity (latency) and bandwidth?
In the guide, philippe_44 says "Network bandwidth and CPU: this requires 1.4Mbits/s per player (plus some overhead), so this puts a fair amount of constraints on your network and CPU"

I've been using the plugin with an Airport Express (wired), a Loop (sitting 2m away from the AE) and an AppleTV 1 (2 walls away from the AE.) The Loop is unable to work properly, Airplay bridge or not, when signal strength dips noticeably under 60%. The Apple TV 1 seems much more resilient.
As for ping, the LMS server on my network pings the Loop on wifi around 2ms on average, but the max is near 10ms (and on my usual VM server max is 30ms.)
In this environment, little to no drops for me.

[castalla]

I suppose you're on wifi? How does it fare wrt to ping regularity (latency) and bandwidth?
In the guide, philippe_44 says "Network bandwidth and CPU: this requires 1.4Mbits/s per player (plus some overhead), so this puts a fair amount of constraints on your network and CPU"

I've been using the plugin with an Airport Express (wired), a Loop (sitting 2m away from the AE) and an AppleTV 1 (2 walls away from the AE.) The Loop is unable to work properly, Airplay bridge or not, when signal strength dips noticeably under 60%. The Apple TV 1 seems much more resilient.
As for ping, the LMS server on my network pings the Loop on wifi around 2ms on average, but the max is near 10ms (and on my usual VM server max is 30ms.)
In this environment, little to no drops for me.

Same player on upnpbridge has no dropouts. On wifi.

[castalla]

The difficulty is that players tend to buffer much more when being driven through UPnP. Do you have a log of the AirPlay Bridge ?

No log - I can try one later.

edit: here's a log - probably not much use as the stream didn't stop after 1 hour. The random nature of the dropouts will make this issue a drag to pin down

[philippe_44]

Booohoohoohoooo... I've removed my dev install and now I get redirection limit exceeded when I try any of the 2 repo urls
(so LMS always wants to restart to finish install and fails and asks again for a restart...)

Sourceforge is in a serious state of flux, shall we say...
Perhaps it's time to revert to manual install instructions?
(BTW, since I can't really live without the plugin, I started my test machine which still has dev-11...

Damm it ... there is no 's' on /project/ and I had to do that mistake on that 1st post of that thread

I noticed your sox magic does not seem to work with remote library URLs.)

I don't quite understand

I have 1 source to the left of a small room where I am sitting and 1 source on the right, nearby. Speaker systems are *not* the same. Sync is perfect but I can feel the "stage" shifting from left to right (and back) from time to time. Yeah, I know that's scary... I think (not verified) this is related to 10ms player sync adjustment events within LMS. 10ms is the minimum value in the web interface. Is it possible to go lower?
Please disregard if this doesn't make sense.

There is another option which is to indicate to LMS that each "sampling point" are not 'fully' accurate and must be averaged out. This is an option you can set when the player is being registered. The result is probably that LMS will do adjustement more slowly but that would prevent that effect from happening. Today, I can't do below 10ms as I'm using "sample point" every 8 ms to LMS, so ther accuracy is +/-8ms. Again, mean is centered but if you take every point for an accurate value, then LMS might do shift a bit too often (you can see in the log that there are often adjustement of "skip 441 frames = 441/44100 = 10ms)

[philippe_44]

ANNOUNCE: AirPlay Bridge = integrate AirPlay devices with LMS (squeeze2raop)

Same player on upnpbridge has no dropouts. On wifi.

No log - I can try one later.

edit: here's a log - probably not much use as the stream didn't stop after 1 hour. The random nature of the dropouts will make this issue a drag to pin down

I think you put me on the right track ... if a player has enough to buffer PCM in UPnP mode, it should be able to do the same with AirPlay. So going small buffer was the wrong direction (I did that at the beginning because I was mislead by another bug). So I think now the problem is an overload I was creating on the host & guest UDP/IP stacks by sending audio too quickly. I've now paced that much more efficiently and it has been flawless on my system since then. Increase the buffer to at least 3000 ms and then try again. Use version 0.1.0.2-dev-1 in the dev repository, this is the only version where it works. Your feedback would be highly appreciated !

[castalla]

I think you put me on the right track ... if a player has enough to buffer PCM in UPnP mode, it should be able to do the same with AirPlay. So going small buffer was the wrong direction (I did that at the beginning because I was mislead by another bug). So I think now the problem is an overload I was creating on the host & guest UDP/IP stacks by sending audio too quickly. I've now paced that much more efficiently and it has been flawless on my system since then. Increase the buffer to at least 3000 ms and then try again. Use version 0.1.0.2-dev-1 in the dev repository, this is the only version where it works. Your feedback would be highly appreciated !

Testing now ..

One thing I've noticed - I have to start a stream twice to get any sound when the device is first discovered.

[castalla]

Tested with BBC live stream - 4 hours without dropout.

[epoch1970]

First thing first, 0.1.0.2-dev-1 works great for me.

There is another option which is to indicate to LMS that each "sampling point" are not 'fully' accurate and must be averaged out. This is an option you can set when the player is being registered. The result is probably that LMS will do adjustement more slowly but that would prevent that effect from happening...

I have looked into the logs, and I can correlate the audible "soundstage shifts" in my sync group (SB3 and AE, wired, 3 meters apart) to Slim::Player::StreamingController::_CheckSync "resync:" events.

I noticed that when the SB3 resyncs, typically at the beginning of a song, usually no audible shift happen afterwards. If the software player resyncs first at the beginning of a song, usually the SB3 will resync moments later, with an audible shift.
With the SB3, resync logging and audible shift happen at the same time. With the software player, the audible effect seems to be delayed by the value of the network buffer option.
I also looked at an SB3 sync group, one wired and one wifi; resync events are a rarity, even over track changes.

I tried setting the "Minimum Synchronization Adjustment (ms)" option to 1000 on my software player to see the typical values of "playPoints:", then set it to 30ms, most playPoints being under this value. This removed the audible "shifts", but degraded sync quality.

The exercise is probably vain. With sources something about 6 m. apart instead of 3 m., when a sync event happens I cannot perceive any audible shift. And I ran this test on my "soft" LMS VM machine anyway.

I did not resist ordering a Zipp mini any longer... Can't wait to put it in service as a stand-alone squeezebox

[philippe_44]

First thing first, 0.1.0.2-dev-1 works great for me.


I have looked into the logs, and I can correlate the audible "soundstage shifts" in my sync group (SB3 and AE, wired, 3 meters apart) to Slim::Player::StreamingController::_CheckSync "resync:" events.

I noticed that when the SB3 resyncs, typically at the beginning of a song, usually no audible shift happen afterwards. If the software player resyncs first at the beginning of a song, usually the SB3 will resync moments later, with an audible shift.
With the SB3, resync logging and audible shift happen at the same time. With the software player, the audible effect seems to be delayed by the value of the network buffer option.
I also looked at an SB3 sync group, one wired and one wifi; resync events are a rarity, even over track changes.

I tried setting the "Minimum Synchronization Adjustment (ms)" option to 1000 on my software player to see the typical values of "playPoints:", then set it to 30ms, most playPoints being under this value. This removed the audible "shifts", but degraded sync quality.

The exercise is probably vain. With sources something about 6 m. apart instead of 3 m., when a sync event happens I cannot perceive any audible shift. And I ran this test on my "soft" LMS VM machine anyway.

I did not resist ordering a Zipp mini any longer... Can't wait to put it in service as a stand-alone squeezebox

I've made 0.1.0.2 the stable version (I think it deserves its name this time). I've also added a 0.1.0.3-dev-1 for you in which I don't tell to LMS that my "sample points" (reporting time) are accurate, so LMS has to do a bit of averaging before changing sync. It seems to me that the phase shift effect has diseappeared (probably at the expense of a slower de-sync recovery when a spike happens). Let me know what you think