Why is internet radio on my Naim network music players unusable?

Weird. My SuperUniti plays Internet radio happily for hours. 

I think there was a thread a few weeks back on this topic.  Worth having a search for that. 

Yes I did a search prior to my post and all I could find was internet connection issues etc. I found nothing that explains why a Unitiserve SSD and a 172 side by side both wired to the same network and the UnitiServe SSD streams internet radio all day without stopping while the 172 can't keep it's buffer for for more that a minute or two... stopping and starting all day long. I have an NDX that can't keep it's buffer full either. All three devices use the same network same internet connection. So the streamers can't keep their buffers full on 320K streams by the UnitiServe SSD can. Strange. 

 Same here ... via wifi

Odd,I have exactly the same problem as the OP, but never with Linn radios.

I have the same problem with my UnityQute on wired network.  Constant dropouts on Naim Radio and Radio Paradise at 320K.  Lower bit rates work well.  I have a high speed connection, and no other bandwidth issues.  

I have assumed it was at the server end, or somewhere in between - I am in the US Northwest.  

Charlie.

I'm having the same problem with 256 and 320kb/s streams on my NDX. I have reset all settings and it has made it worse. It wouldn't even play now. Not even with Naim radio. 

I think the problem with HiDef streams is that it won't keep the buffer full at 100%. It will only fill the buffer when it's empty. It stayed at 100% with 128kb/s or lower streams. Hopefully it's only a software issue.

A silly question, perhaps, but...

Do you know if you are being bandwidth limited by your internet service provider, in case this is relevant?

I learned the hard way that Virgin Media was severely restricting the bandwidth to our home, whenever our kids were home from University.  We would have 4 people in the house playing team Starcraft games for hours at a time during the holidays.  Apparently, the data flow is so high when this happens, that we were hitting our maximum permitted monthly data flow rates, every month.

And I didn't even know that there were such limits, as we were thought we were paying for a 10MB speed connection.  However, buried in the small print are data limits as well.  Once we hit the limit, Virgin Media would restrict the speed of our connection down to between 10% and 25% of our contracted connection speed, which played havoc with all internet connections.

After calling out repair engineers on 3 occasions to fix the apparent problem, I finally found out what was going on and upgraded our connection to a 60MB line with higher monthly data limits.

So there you go, it seems we are all contractually limited on total monthly data volume, even if we don't realise it.

The only way to find out if this is happening, is to call the Customer Services line of your ISP and ask if you are being "Bandwidth Managed".

Not sure if this is part of the answer, but helpful to know if you stream a lot of stuff over the internet 

Best regards

FT

Good info FT - out of curiosity (and if you don't mind sharing) how much extra $ did Big Brother want for the increased bandwidth?

As I type this (10AM Monday morning) I’ve been listing to 320K Radio Paradise for the last 1.5 hours with without a single stop for rebuffering. This has happened before where it will work fine for a listening session and then when I listen again it can’t play for more than a minute without stopping to refill the buffer. Like others have noted my Naim internet radio works all the time as long as you don’t try to play the 320K stations. Perhaps the 320K streams are just too high quality and the Naim hardware & software is not up to the task of such a high quality source? Oh I kid (I’m joking with) the Naim people. Yet that cheap mid-fi Sonos stuff works flawlessly with 320K MOG and Spotify streams... how does that saying go “if it works the first time or all all the time it’s not high end”  This is proof positive that Sonos is NOT high end as it just works.

To FT’s question. If it were a bandwidth throttling or limiting issue I’d see problems with my AppleTV, Netflix streaming, Sonos 320K streams right? As they all use the same connection. Just my wife and I at home. No gamers. I never ever get close to using my 250GB per month data cap that my ISP Comcast (Utah USA) has. It’s worth noting that the Comcast web page states the 250GB per month data limit is currently NOT being enforced and has never been enforced as far as I can tell. I just ran a test on my internet connection with speedtest.net while Radio Paradise 320K was playing through my 172 and I get 54.64 Mbps down and 11.04 Mbps up. 95% of my attempted internet radio listening on my naim gear is during the day in my home office. The middle of the day is when most people are at work and the residential internet use is way down. 

Over the past year I’ve been tinkering with naim iRadio with a handful of naim network players including the original Qute, Uniti, SuperUniti, 172, NDX. They ALL have this 320K stream buffering issue more often than not. The only naim device that I’ve played with that doesn’t have this issue is the UnitiServe SSD. Now the SSD by it’s very nature has a BIG buffer right? It has to, that’s how it works. The SSD rips the CD to WAV files. It stores the CD in it’s flash memory and then dumps the WAV files to the NAS when the CD is done being ripped. And low and behold the SSD is the only naim device I’ve found that seems to be immune from this 320K buffering issue. So I must conclude that naim blew it with the network streamers by not putting a large enough memory buffer in these units to compensate for the data rate / speed issues inherent with internet streaming. I have no idea if this is a naim streamer software issue, hardware issue or perhaps both? But it’s an issue for sure when my $349 Sonos Connect box can stream 320K until the internet or the power goes out while my $3200 naim network streamer (more often than not) can’t get through a few minutes without stopping the music to re-buffer. It just blows my mind what we audiophiles put up with. 

ps my hard wired 172 just stopped to rebuffer. So it appears I’ve reached my limit of uninterrupted iRadio for the day on a naim network streamer. I’ll need to switch to my UnitiServe SSD if I want to keep listening to the 320K Radio Paradise stream on naim.

I have called my ISP and there is no traffic shaping with my internet connection. There is no problem streaming 320kb channels through my iPad so I can safely rule that out. My NDX is the 2012 version with latest spec so I am surprised that it struggles with HiDef streams. The next step is to update the firmware to 3.17 version and hopfully that will fix it.

+1

You can test your connection quality with tools like pingtest.net. With my ISP, the quality for streaming from US is not perfect and might explain why I get dropouts on my UnitiQute when playing 320K radio, this happens mainly evening time in Europe in my case.

Radio Paradise have streaming servers also in UK but I don't know how my UQ selects the streaming server for 320K.

The solution is probably not as easy as increasing the buffer size. Companies like Spotify or Sonos have spent many manhours developing clever streaming technologies to handle exactly the issue with varying connection quality. There is a Spotify White Paper for those interested. One issue is that most broadband connections are asymmetric and while downlink streaming is ok, the ACK going uplink might be delayed.

A few points.. To see what really is going on one would need span the NDX switch port.. But I have also very occasionally seen this on my NDX - a kind of pulsating buffer - , and is fairly specific so far to Naim and so perhaps some optimisation of the media buffering to TCP segment windowing algorithm is required on the streamer board.

BTW traffic shaping is used to improve performance where the data throughput is potentially greater than the the throughput of a link or TCPIP stack. The NDX TCPIP stack will use shaping techniques to dynamically set the TCP window segment sizes and a quality Internet router should shape as well. It is better to shape than traffic  police, as the latter doesn't allow the TCP stack to adapt.. This allows for the optimum transfer of data without overloading the NDX whilst maintains an efficient connection with the peer.  I do think this area is where I would investigate if I were Naim, and track it with Wireshark. Perhaps look at capability with out of sequence segments.

ADSL connections are by their nature asymmetric however the delay of the segment NACK on the upstream will be minimal before its discarded as there is very limited queing in the router. If discarded, that segment will be sent again.. This is is also one parameter that is determined dynamically with the TCP stack, if there are many failed discards then the TCPsegment window is (should be) reduced.

However TCP segment windowing is at quite a lower level than the application buffer.

Simon

Simon good points.

It was a while ago since I was working with communication design, I am in sales now and sales people too quickly tend to forget all their technical skills  

I do find the streaming area interesting though and I am planning to hook up Wireshark to my UQ or ND5. They live in different locations though with different ISPs. The ND5 is connected by cable and the UQ by ADSL. I rarely have buffering problems on my ND5.

I was going to look into ACK Compression on asymmetrical connections, that several ACK arrive in bursts. Do you think this could be one issue here?

Indeed ACK compression may be upsetting things.. It would be interesting to see if it were the case which peer or direction is bottling up the ACKs.

It would be interesting if one saw the pulsating buffer with an Internet streaming station, to do a Traceroute and see what the trip delay is. Then compare the trip delay when the buffer is working.. If there was a difference then it might point to ACK spacing issues upsetting the TCP effective  throughput clock. 

It just goes to show TCP doesn't get you out of jail compared to UDP with near real time data flows.

Some interesting strategies ( for the stack designers) here:

http://www.softwareopal.com/qo...ult.php?p=gen105-tcp

Simon

Too many guessing explanations with inaccurate, mis-leading details about how TCP/IP or multicast streaming works. The fact that Naim Radio has a problem whereas Linn radios work fine, although they are all transmitted at the same  320kbps rate suggests that the problem is at source. But having said that, Naim radio has outstanding sound quality when it works.

I too have 320kbps drop out problems with wired connection to my NDS, but if I switch to wi-fi it works just fine. The NDX I had before was the same. Luckily most of the time I listen to internet radio when I am sitting in front of my PC so Naim's drop out problem does not affect me too much.

Down here in NZ, just tried radio paradise 320k stream on a wired connection into an ND5, buffer drops away. Use a wireless connection with a high gain antenna and the problem goes away. I believe this to be because the buffer is larger when using Wireless, as it has to compensate for errors more often.

Peter, Internet radio does not currently mostly use multicast streaming( which is hugely different) , it uses session based unicast TCP, which is was Olliemate and myself were debating quit accurately ( I feel I can comment as I design such networks and systems  professionally) . The ACK compression is symptom of bad segment acknowledge timing from the peer (either peer) or transmission route  causing effectively throughput issues due to the TCP windowing timing being upset.. If you like TCP segment window  jitter.

Olliermate made a good point that this might be an issue from a less than ideally optimised TCPIP stack in the NDX etc (which would show up with certain peers or transmission routes). Again we have suggested for anyone one with the engineering ability to Wireshark and Traceroute thdata traffic into their NDX when they get the pulsating buffer issue. That way the hypothesising can possibly stop and the findings be passed to Naim, as almost certainly the 'issue' will become very evident from the trace. If you are an engineer like me you need to start with a hypothesis to progress an investigation. Be interested to hear your suggestion.

The challenge is capturing the trace when the issue occurs.

As data engineers know, digital transmission is far from  black and white, it is a hugely variable and dynamic area, where issues can only show up in certain conditions.

Simon

Edit looking at user comments such J Saville, it is increasingly pointing to transport (TCP) ACK timing issue with respect to the application buffer related. 

I have very occasionally seen this behaviour on BBC3HD - which is also 320kbps, but not so far RadioParadise.

Just a thought, there is a chance this might be resolved or mitigated  in the forthcoming 3.21 .. We will wait and see.

Got Wireshark hooked up, some initial findings for those interested. Radio Paradise 320K is streaming session based Unicast TCP from a server in London. traceroute shows a stable roundtrip delay to the server (100 ms).

Receiving Window Size around 6300 bytes, max 8192). Didn't come across the network buffering issue this evening, however I tested starting an upload of a file increased roundtrip delay significantly to the streaming server. The upload didn't affect Spotify or Sonos but my UQ where the UQ stream jitters with long delays between TCP packets, and the end result is an empty buffer, part of the reason is because receiving window size is not increased when congestion occurs.

Disclaimer: it was a while (years - decades?) since I was working with this stuff so please take it for whatever it is worth

Ollie

Hi Ollie under congestion when theUQ buffer emptied, did the window sizes increase; ie the frequency of ACKs decrease..that is when application buffer emptied was there there any impact to the TCP behaviour, did you see TCP window scaling being implemented? Perhaps it does point to the application buffer or the TCP scaling buffer  simply not being large enough on Naim  streaming board on the under ADSL uplink congestion when the ACKs are delayed or timing compressed. I wonder if those some of the new 1.4Mbps services are seeing more frequently.

Simon

BTW were you spanning a switch port, or sniffing a half duplex hub?

To check for scaling look at the TCP options and look for a windows scaling multiplier dynamically changing when the app buffer runs out mid session.

http://packetlife.net/blog/201...-and-window-scaling/

Hi Simon, the window sizes kept constant at 6774 almost all the time, one would have thought that maybe some more dynamics was needed to tell the sender that the buffer needs more data. The ACK seem to be sent in bursts of 2 or 3.

Scaling factor is "-1 unknown".

I was using a 5 port Netgear switch with port mirroring.

Hope that helps.

Ollie