raglencross wrote: > Philippe, I am holding off on sending you the requested debug file for > the Soundmate because I have just found out that if I enable encryption, > as you suggested to USC95, I end up with exactly the same symptoms as > him i.e. sound that cuts in and out and is garbled. Per your > instruction to USC95, I have tried setting the Radio Station Buffer to 6 > seconds with no success on a local flack file and a MP3 stream. This of > course is progress over having no sound at all. Do you still need a > raop debug run from me to help you trouble shoot the problem?
I'm not sure where to take it from here, especially on the ATV4 as I don't understand why the result would be so different between epoch1970, mine an your setup, knowing that we use the exact same device. The soundmate is probably as you described, using ShairPort whcih requires encryption. But if now you have same garbled sound with cut-offs on both devices, I can't find a reason why. You can try to reduce the "networking buffer" in "AirPlay options" from 3000 to 1500 or 1000 (in the plugin settings), but I doubt this will solve the problem. I'll try to describe the problem as sometimes explaining things helps finding a solution. Sorry if it's getting too technical, but maybe somebody will have an idea (this is the first time I'm implementing the AirpLay protocol, but I looked at what others have done and read a lot about it as well) The AirPlay protocol requires audio stream to be sent "in real time", but of course some buffering is always required in the AirPlay device as one have to accomodate for some network congestion. The AirPlay v2 protocol also uses UDP for sending audio, which means that there is no acknowledgement / flow control of audio, so the sender "shoots in the dark" (although the receiver can ask for re-sending of lost packets that are detected using an increasing sequence number, so there is a control :)). So what I'm doing is sending quickly up to 3s of data (or whatever the parameter above is set to) and then, based on the clock of the local computer, I'm sending the rest of the audio track in "average real time" (in other words, and to over-simplify, I'm replenishing the 3s buffer every 100ms). The clock of the AirPlay device is constantly adjusted to the clock of the local computer, that's part of the protocol, so if there is no over/under run on the local computer, there is no over/under run on the AirPlay device. In other words, if the local computer estimates that the buffer in the device is fill with 2.5s of audio, it is *really* filled with that, so "replenishing" is accurate. Knowing that there are 2 reasons potentially for cutoffs. 1- underrun: Not sending fast enough, so the receiver is missing audio data. That would mean that either the network bandwidth is ridiculously low or that the bridge is not receiving enough computer CPU to send audio fast enough 2- overrun : Sending to much data (ie, assuming that the audio buffer in the device is big enough to hold 3s of data, but it's not) One can add a bug in the time synchronization, but I've tested that a lot and I have it working with 4 different devices, and epoch1970 is experiencing the same. For people using an ATV4, the overrun is probably ruled out or we would all experience the same problem. This leaves me with an underrun, but I really can't see how it could happen with any decent computer. Again, I've run test on a raspberry Pi B (not the 2, only the B), only connected using WiFi and with 3 devices playing in parallel, all requiring the Pi to do resampling and flac/mp3decoding. It loaded the Pi around 20%, so it does not seem to be an overload problem ... LMS 7.7.5 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos 2xPLAY:1, PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBMC, Foobar2000, XBoxOne, JRiver 21, Chromecast Audio, Chromecast v1, Pi B2, Pi B+, 2xPi A+, Odroid-C1, Cubie2 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=105198 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
