Help-Unitiqute dropping Linn HD radio
Posted by: Clay Bingham on 28 May 2011
Friends
Need your advice. The problem: I can't listen to Linn's high definition radio stations without getting drop outs every minute or two. Buffer display on Unitiqute slowly gets smaller until it disappears and so does the music. Half a minute later ( or so it seems!) buffer display returns and music is back. Having checked the search function and troubleshooting guide I still haven't figured out exactly what is going on here. Three other Unitiqute owners including my dealer report having the same issue, all living in Southern California.
In common, we are all connected to broadband internet service through our local cable company, in my case, Time Warner. The service comes by fiber optic cable to the house and then through high grade coax in and through the external house wall. The coax is in turn connected to an eMTA cable modem. My modem is a Motorola SURFboard 3B5101U USB cable modem. The problem occurs whether, as in my case, you use a ethernet cable connection from the modem to an Apple Airport Express ( problem also occurs with Airport Extreme) or alternatively connect the ethernet cable directly from the modem to the Unitiqute.
Has anyone had a similar problem? Any help you can provide will be much appreciated by at least four of your fellow Unitiqute users.
Thanks in advance.
Clay
Posted on: 28 May 2011 by DavidDever
Hi Clay, I spoke with your retailer and asked that you contact us directly to provide us more system configuration details:
naiminfo@soundorg.comPosted on: 28 May 2011 by T38.45
Hi Clay,
have the same problem with Linn radio here... other 320kb stations streaming without connection problems.
Ralf
Posted on: 29 May 2011 by Simon-in-Suffolk
Ralf, Clay,
Yes I noticed this on Friday evening. Might be that Linn servers or Internet access is running out of capacity, ( certainlly if it uses regular Unicast addressing as opposed to multicast.)
For Internet or web radio without user limitations strictly the server needs to transmit in multicast but these are very very rare, otherwise what we are using is really AoD or audio on demand and is individual session based and is constrained to the number of streams that can happen at once through the host server and Internet access.
Simon
Posted on: 29 May 2011 by Clay Bingham
Thank you for the replies. Ralf, we're not alone with this issue so I will definitely post what I learn. Simon, your thoughts sound very similar to thoughts my dealer had. His other thinking being that there may be a buffer configuration or buffer size issue with the Unitiqute. David, I will send all the set up details after Memorial Day.
Thanks again for the help.
Clay
Posted on: 30 May 2011 by gary1 (US)
FWIW, it dd the same on my IPad 2 after about 15 minutes of play. Had to bac k out and re-enter the link and station.
I think it is them and not your Uniti.
Gary
Posted on: 31 May 2011 by Clay Bingham
Thanks Gary
Basic analog was sooo easy!
Clay
Posted on: 31 May 2011 by Phil Harris
Hi Guys,
The Uniti / UnitiQute and NDX buffer a few seconds worth of audio at 320kilobits which is normally more than enough but there can well be a lot of hops between the start and end of the streamed audio chain - once it is "broadcast" then the data is passed between servers out on the internet until eventually it reaches you.
It is perfectly feasible that the route that the data takes can be delayed (blocks of data may even take quite different routes) and neither we (Naim) nor the broadcaster (in this case Linn) have any influence on that - the practical result of this is that if the latency of the connection between the start and end of the chain gets too great then the buffer eventually empties before there's enough data coming in to replenish it. Of course - lower bitrate streams mean that we can buffer a longer duration of audio and so cover over longer drops in data before buffers empty and you get a dropout.
PCs don't suffer with this so badly as they can generally pre-buffer more data to take account of high latency connections but eventually they will suffer the same issue if the overall average data rate from the source isn't high enough and consistent enough.
We have tested the Uniti / UnitiQute and NDX on 320kilobits streams and they are all more than capable of playing such streams given most expected conditions however we cannot cover *ALL* situations - if a lower bitrate stream is available then choosing that should resolve the issue.
Cheers
Phil
Posted on: 31 May 2011 by Clay Bingham
Phil
Thanks for a clear explanation of what is happening.
Appreciate your time.
Clay
Posted on: 31 May 2011 by T38.45
Thanks,
just tested with another streamer...same issues here, guess it's a broadcasting problem...
Ralf
Posted on: 01 June 2011 by Phil Harris
Originally Posted by T38.45:
Thanks,
just tested with another streamer...same issues here, guess it's a broadcasting problem...
Ralf
To be accurate, not a "broadcasting" problem as such, more a transport problem...
Phil
Posted on: 01 June 2011 by Simon-in-Suffolk
Ralf, yes the problem is that Linn are NOT broadcasting, they are providing on demand streams. They would appear to be running out of capacity over their Internet connection, so some of these individual streams are getting congested and delayed or if severe enough the TCP connection will be closed or abandoned.
If Linn were broadcasting, or more accurately in network terms multicasting, this would not be an issue, and Linn would only need the capacity for one stream of each web station streamed no matter how many people receiving it. However I suspect until IPV6 takes off for ISPs, or even IGMP is widely adopted for IPV4 ISPs we will see very few multicast web radio stations, and so congestion and low bandwidth will remain issues for web radio.
Simon
Posted on: 02 June 2011 by T38.45
Thanks all for reply,
I will enjoy other stations instead...there are many to explore....
Posted on: 02 June 2011 by Phil Harris
Hi Guys,
The info I have is that Linn stream their "radio" as Unicast - this is then usually passed out to a remote shoutcast server that works as a cache at the ISP (so that they aren't handling the multiple connections away from the main backbone). On connecting to their cache server you then have a TCP stream of http: gets which go from their server to your client however you don't have your own unique instance of the stream back to Linn.
I understand that the Linn stations have quite a low max concurrent user count on them (I'm told somewhere in the order of 500 or so) so once that limit is reached you should simply find that you get a refused connection or you get kicked off (depending on what rules they have set for how long they wish to allow people to remain connected in situations of high demand).
If you are getting dropouts and glitches in the audio stream then that isn't down to Linn and what they are piping out as the feed for their station - that is almost certainly down to latency and / or a steady proportion of packet loss between their caching server at the ISP and you...
You should also be aware that there is the provision for a *SIGNIFICANT* amount of traffic shaping to go on in ISPs ... certainly it would seem not-too-unlikely for large providers that have their own streaming media services to prioritise their own streaming media traffic (that which generates them income) at times of high network activity over traffic which does not generate them income yet ties up a significant portion of their bandwidth...
Cheers
Phil
Posted on: 02 June 2011 by Simon-in-Suffolk
Phil,
Thanks it sounds like the issue is with Linn's Internet border gateway connection profile from their caching server / proxy provider to the Internet. The traffic shaping will be at the border between the ASs., but traffic shaping basically allows for optimum or regulated transmission over given link capacity to stop particular connections hogging all bandwidth across that border/interface at the expense of others. As each web radio tcp stream will use the same bandwidth, I can't see what shaping will do other than guarantee optimum bandwidth for a given number of sessions for each of the caching servers clients such as Linn, but it sounds like if there is TCP breakup this shaping has become none optimal for the load profile/ number of concurrent sessions and should be repairable which is good news for those that listen to Linn web radio.
Once you are on the Internet and use a significant service provider autonomous system such as BT, Virgin etcthe bandwidth is tremendous and this sort of traffic would trivial. Peak Internet traffic in the UK usually occurs when kids get home from school at 4pm/5pm and start facebooking and utubing, the spike is quite significant and fascinating to watch in a backbone management centre.
Simon
If the web radio is indeed using TCP as opposed to UDP there should be no packet loss, unless their server or caching proxy server is closing TCP sessions mid transmission through extreme over load, and TCPs window mechanism is unable to recover the missing segments.
Also big stream loads such as BT vision use an overlay network that provides the streams before you reach the Internet backbone ( even though as a consumer accessing the Internet it appears the content is coming from the Internet) The vision system then distributes the content to regional caching servers across the UK so as to avoid loading the UK backbone.
