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

[philippe_44]

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

[philippe_44]

Testing now ..

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

I think I've found why (an optimization to avoid sending silence when nothing has to be played) - I'll correct that soon

[epoch1970]

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 .... Let me know what you think

Fantastic! Will do!
EDIT: I'll post in the "Experimental" thread. No need to monopolize this one on account of my obsessions.

[epoch1970]

I'm running LMS and the standard squeeze2raop-x86 executable on a pc engines Alix machine, "powered" by an AMD Geode LX800 running a custom linux 4 kernel.
Works perfectly fine. Takes 7-10% CPU, very efficient.
The Airplay bridge will be up during summer days. Great!

[davidlymburner]

Had the AirPlay bridge working fine with my Samsung DA-e750 for a few days, but now it will only play the first 1-3 seconds of a track with static&flutter before discontinuing all sound output. The controller shows the track as still streaming to the player, but there is no sound output. Streaming To the device still works fine using Pandora/AirPlay on my iPad. Any ideas where things might be going wrong?


Sent from my iPad using Tapatalk

[philippe_44]

Dis you upgrade to a new version ? Can you post tour configuration file and a log (all found under the plugin setting page)