Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27
  1. #21
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,798
    Quote Originally Posted by netmax View Post
    OK, I've had a 3-4 seconds break here and I had a look to my capture ... that one looks like a lag from the radio station server.

    One lag of 5 seconds and then another one for 7 seconds ... too much for any buffering.
    Without the raw wireshark log I cannot confirm but 7 secs is not unusual. How much data is sent in each burst ? what is the data rate of the audio stream ? calculate how long each burst will take to play . With MP3 format SB hw players have an internal buffer can hold minutes of audio - not sure what airplay bridge is setup.

  2. #22
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    Hi @bpa,

    Please describe your network setup in detail as I think this is the first time you have said Squeezeplay was over VPN but Airplay was local to LMS. Does that means Airplay device does not involve VPN even to the station (e.g. wired locally to LMS) ?
    The VPN is only in place to connect my computer in the office to my home server to listen music here. It's a SqueezePlayer running on Windows.
    All Airplay devices are at home, without any VPN and all with a direct wired connection to my home network (including my servers).

    I've checked the three servers in the .pls file. Two are located in the US (~100ms ping time), one is in Amsterdam/Netherlands with 14ms ping time. I've now changed the link in LMS from the .pls link to the direct stream links, so I can exclusively choose the server and LMS does not all this negotiating when starting the playback to get the best server.

    It seems the "best" server might not be the best server. The Netherlands is quite close to Germany where I'm located, the ping is ways better but this stream seem to face issues by lagging for sometimes more than 10 seconds. I see at least >2 packets every second in the wireshark traces (more than 1.5 kilobyte ... I'd have expected less for a 128 kBit/s AAC stream), but if the playback is fine that can be seen constantly. The huge gaps, if occurring, causes the hickups in playback.

    The US server, even with a 7 times worse ping ran pretty stable without any issues during the afternoon.

    I'll play around a bit with the different servers and let you know the outcome. Maybe the NL server is the issue ...

  3. #23
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,798
    Quote Originally Posted by netmax View Post
    It seems the "best" server might not be the best server. The Netherlands is quite close to Germany where I'm located, the ping is ways better but this stream seem to face issues by lagging for sometimes more than 10 seconds. I see at least >2 packets every second in the wireshark traces (more than 1.5 kilobyte ... I'd have expected less for a 128 kBit/s AAC stream), but if the playback is fine that can be seen constantly. The huge gaps, if occurring, causes the hickups in playback.

    The US server, even with a 7 times worse ping ran pretty stable without any issues during the afternoon.

    I'll play around a bit with the different servers and let you know the outcome. Maybe the NL server is the issue ...
    IMHO With audio network dealys and congestion are rarely the main issue as they are serving many many users. If they are a bit slow then they are exposing an issue in your setup.

    I don't use VPNs so I can't go into great details but from other users, I know VPNs can cause "odd" problems - is it a real VPN or just one that messes with DNS ?

    edit:

    Just to confirm the audio stream are normal stream used by many users and not just a niche stream which serves only a small number of users ? Do the servers in different countries belong to CDN such as Akamai, Limelight etc. - you can tell by the URL of the station
    Last edited by bpa; 2017-11-21 at 10:53.

  4. #24
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    Quote Originally Posted by bpa View Post
    I don't use VPNs so I can't go into great details but from other users, I know VPNs can cause "odd" problems - is it a real VPN or just one that messes with DNS ?
    Just to confirm the audio stream are normal stream used by many users and not just a niche stream which serves only a small number of users ? Do the servers in different countries belong to CDN such as Akamai, Limelight etc. - you can tell by the URL of the station
    The VPN is not in place between my LMS server and the radio stream! VPN is only used between my office PC and my servers at home to be able to stream the music from my LMS (OpenVPN connection). The LMS gets the internet radio streams via "normal" internet connection (50/10 MBit DSL line with fixed IP)

    The audio streams are from audioaddict (https://www.audioaddict.com). Servers are i.e.:

    prem1.radiotunes.com (US, near NYC)
    prem2.radiotunes.com (Amsterdam, Europe)
    prem4.radiotunes.com (US, near NYC)

    I guess 1 and 4 are hosted in their own datacenter (and they seem to be stable so far!).
    2 is the Europe server and it introduces itself as a CDN:
    Code:
    inetnum:        185.76.10.0 - 185.76.10.255
    netname:        CDN77-AMSTERDAM-3
    descr:          CDN77.com Amsterdam (Netherlands) POP
    country:        NL
    admin-c:        DLTS1-RIPE
    tech-c:         DLTS1-RIPE
    status:         ASSIGNED PA
    mnt-by:         DATACAMP-MNT
    mnt-by:         SUPERNETWORK-MNT
    However, that CDN network is unknown for me. LMS uses that one when the Playlist link is used (I guess because of the better ping?). But that one seems to be the one causing the drops, the US servers are playing well so far. I need to negotiate that a bit more.

    I'd be happy if the issues can be tracked down to a particular server. If the US servers are fine after some days, I'll shoot a mail to Audioaddict pointing out the issue. But I need more input here which can only be gained by listening more hours on the US server.

  5. #25
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,810

    about AirPlay bridge

    The interface to LMS is a squezelite modified to be multi-instanciated, but other than that, it's super close to squeezelite in term of LMS protocol. There are 3 levels of buffering, as in squeezelite:

    - streaming buffer that receives HTTP stream either from LMS or directly from the internet stream. By default 2MB ==> make the calculation according to the bitrate, but that' a lot
    - decoder buffer : where the raw decoded data are stored once they are converted to 16/44.1 ==> 2MB again (I think but it's parametric) == 2048/(44.1*2*2) = 12s
    - output buffer: where the data with replay gain, fading etc is store ==> 2MB again

    Then raw audio is sent to AirPlay devices by chunck of 352 samples (=1408 bytes), so more or less every 8ms, with 1 to 2 seconds buffering made *by* the AirPlay device (RTP streaming). I won't descrbe how the 8ms pace is kept and how the sync is maintained with LMS it caused me a lot of headaches, but I'm sure there is no issue here (at least that would cause what you observe)

    I don't think the communication with LMS can be the culprit, there is a lot of buffering. Unless you network is really bad, the AirPlay part is rarely the issue for such long blackout (it's RTP, so lost packets are lost packets, realtime continues no matter what, a blank of 2-3s is a big blackout - things would be very different with TCP of course), but still it's more sensitive than the LMS part. Note that even if there are lost UDP packets, it does not suspend the LMS connection part, they are independant threads.

    You could have a "thread starved" for a few seconds, but I don't believe that has any chance to happen - never seen that

    For me, it's likely the connection with the internet radio server. As AirPlay bridge (as a squeezelite derivative) can directly stream from the internet radio, if that connection stalls for too long, then you'll have blackouts, no matter what. The 2MB streaming buffer does not change anything here as LMS (at best) tells its's players "get that amount of raw data in the output buffer and then start playing", so the 2MB stream buffer is rarely full with a internet radio that stream almost-live content. I have to look at the logs, but this "amout of raw data" it's usually not a lot. I can't remember if that threshold can be changed from the UI. If you can't find any solution, I could build a squeeze2raop that forces that buffer level (before it starts playing) - not very easy to do currently as I'm away from my dev machine, but I can try
    Last edited by philippe_44; 2017-11-21 at 13:58.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  6. #26
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    15,798
    It seems you and Phillipe favor the radio station as the culprit.

    I think you need to test a non audioaddict US stream - and see if the problem happen (e.g. 128kbits/sec AAC from somafm is http://somafm.com/illstreet130.pls )

    These days I never have frequent buffering problems with internet radio streams and I have a slow 10mbits/sec "noisy" ADSL connection. A few years ago the buffering problem would occur either due to poor wifi connections between LMS and player or a live stream with source station capacity issues.
    Last edited by bpa; 2017-11-21 at 14:27.

  7. #27
    Junior Member
    Join Date
    Nov 2017
    Posts
    20
    Hi,

    after some days and a weekend of listening I can confirm it *is* the server. I've shot out an email to Radiotunes/DI pointing to that.

    Thank you all for your support!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •