Huge posted:

 

Fatcat, if a 100base-t network can't refill the buffer in a lot less than 5s then there's a major problem with the network, so 30s is unnecessarily long.  It's no disadvantage, but also no real advantage either (unless the streamer is appallingly slow to react to the buffer dropping below the (full) action level).

 Huge

You’re probably right. But, everybody seems to agree Darron’s ND5 XS Problem is down to problems with his network. Surely the advantage of having a 30 second buffer as opposed to a 5 second buffer, is it will cope with a problematic wired or WIFI network.

The SBT reacts very rapidly to an empty buffer, press play, immediately remove the network cable and it has 15 seconds of music in the buffer.

30 seconds of redbook in the buffer, is no where near full, the buffer has 128mb of ram, which is over 10 min of music, I think.

Huge posted:

Simon, I didn't say that the buffer always had 5s of data, just that it's about 5s (i.e. in length).  The length of the buffer doesn't depend on the amount of data in it, just it's size and the data rate.

Fatcat, if a 100base-t network can't refill the buffer in a lot less than 5s then there's a major problem with the network, so 30s is unnecessarily long.  It's no disadvantage, but also no real advantage either (unless the streamer is appallingly slow to react to the buffer dropping below the (full) action level).

But Huge, what makes you think it's to do with the network? ...My point was about changing the media server, as that has not been ruled out and seems to be if I have read the thread correctly one of the only elements that has not been changed. The network can only convey what it's hosts are instructing it to. It is unlikely on an effectively fully wired Ethernet home network that data  is being lost or delayed to the extent of causing dropouts unless there is a cabling or component fault.

To your comment above, the buffer and I am referring to the TCP buffer is effected by size and data rate and latency and TCP windowing and acknowledgement behaviour.. the TCP buffer is not nnecessarily simply a linear buffer. If the media server is having some sort of issue confirming sent data, then the streamer will be requesting repeat data and discarding data if not received in a timely manner... this will clear or lower the amount of data held in the buffer 'memory'.

i have seen this behaviour occasionally  on a network trace with Naim streamers and its effects are a less extreme version of the Tidal dropout issue. IE media server timing performance.

Simon

Simon, it seems the parts of my response have got conflated.
I wasn't saying that the problem was a network issue in this case, just that having a much larger buffer doesn't generally make up for network issues.

I'm also aware that the buffering in the system is usually not a simple single linear buffer, for instance for gapless playback a ping-pong buffer would typically be chosen, sometimes implemented in a dual circular configuration, and that's only the playback level not the low level comms buffer.

Ok. Thanks for the additional suggestions and patience for all those involved here. Awesome resource. Tonight I will try setting up an alternate server to supply music to the Nd5 XS and see if there are any improvements.

Darron Stepanich posted:

Ok. Thanks for the additional suggestions and patience for all those involved here. Awesome resource. Tonight I will try setting up an alternate server to supply music to the Nd5 XS and see if there are any improvements.

I'm glad to see that Darron is going to try a different server and look forward to reading his findings afterwards.

It's not based on any technical justification, but my feeling is that it's just 'wrong' to use a regular PC as a music server... my experience of trying to resolve people's computer problems shows that general purpose computer operating systems (Windows on PCs) tend to be trying to manage too many other processes at the same time.  They are optimised to respond to user  requests (the mouse moves, the keyboard is pressed, microphone active etc), whereas a music server is optimised to respond to requests for data to be served (sent).  So it figures (in my humble logic) that to have a regular PC serving your music, it has to be a pretty powerful PC in terms of CPU cycles and available memory (RAM), and of course network I/O capability, if it's to do the music serving task effectively... and most PCs that you find in people's homes are not awefully powerful.  And that's why we see dedicated music servers being offered to us, the demanding audiophiles of the digital age... and ignoring this will lead to tears at bedtime  (and dropouts) 

Roger

Roger,

While I agree that general purpose PCs (including Macs) are not ideal as real time servers, this has nothing to do with power - most PC are more than two orders of magnitude (i.e. over 100x) more powerful than is necessary to stream HD music *.  No, the problem lies with the design of the operating systems - the OSes aren't designed to handle real-time tasks efficiently and even when idling they have dozens of small tasks running.  Any task can interrupt any other application level tasks that aren't at running at a highest priority level (and there are special rules for doing that, meaning that you can't do it continuously).

This means that it's impossible to keep the latency down all the time.  Mostly it's OK, but there's always a chance that, occasionally, the PC will become more loaded when routine task just happen to clump together at the same time, and then, somewhere in the chain of software components of the music server (in practice, it's many tasks in series, not just one) something will get interrupted for a bit too long.

* the one exception to this is the hard disk sub-system which is still has a sustained data rate typically fifty times faster than the HD stream.

Yes, a PC can decide that e.g. paying attention to Windows Update is more important than playing music.

The strategy of taking things off the network, and replacing them one-at-a-time, is the right way to go.  'Replacing' the server in the process to see if its at fault is necessary.  When I had a similar drop-out issue, I was able to replicate it with both my UnitiServe and my nas running MinimServer; so I knew it wasn't my server.

rjstaines posted:

Darron Stepanich posted:

Ok. Thanks for the additional suggestions and patience for all those involved here. Awesome resource. Tonight I will try setting up an alternate server to supply music to the Nd5 XS and see if there are any improvements.

I'm glad to see that Darron is going to try a different server and look forward to reading his findings afterwards.

It's not based on any technical justification, but my feeling is that it's just 'wrong' to use a regular PC as a music server... my experience of trying to resolve people's computer problems shows that general purpose computer operating systems (Windows on PCs) tend to be trying to manage too many other processes at the same time.  They are optimised to respond to user  requests (the mouse moves, the keyboard is pressed, microphone active etc), whereas a music server is optimised to respond to requests for data to be served (sent).  So it figures (in my humble logic) that to have a regular PC serving your music, it has to be a pretty powerful PC in terms of CPU cycles and available memory (RAM), and of course network I/O capability, if it's to do the music serving task effectively... and most PCs that you find in people's homes are not awefully powerful.  And that's why we see dedicated music servers being offered to us, the demanding audiophiles of the digital age... and ignoring this will lead to tears at bedtime  (and dropouts) 

Roger

Windows is a prime culprit for hold-ups whatever you're doing on a PC, which Isn't conducive to enjoyable music listening - and in its autonomy increases with every version... Maybe it wont be long before it decides what music you may play!

Macs tend to be better than PCs, although for any 'mission critical' application, which is how I regard music play, the more dedicated the machine can be the better. I've previously mentioned that the Mac Mini makes a good alternative to a standard NAS - being small and easily run 'headless' means it lends itself to sole music use.

And in relation to the negative aspects of using a 'regular PC" as a music server, though not relevant to the OP,  when it comes to running Audirvana as renderer on the MM, it has a dedicated mode that locks potentially interfering functions so they can't be used when playing. That coupled with it being small and easily run 'headless' means the MM lends itself to sole music use, with as already mentioned, the benefit of no network needing to be involved when playing music. 

Latest update:

I setup a secondary PC with Asset UPNP installed and directly connected that to a switch with the ND5 SX. The issue reproduced again in this configuration. So it appears it is not the specific music server machine. That should rule that out.

When the ND5 XS dropped out I also looked at the PC resources. It appears that the networking connection on the machine actually goes down. It seems like something secondary on the network is actually causing a blip in the overall network. It recovers on the PC a few seconds later. It seems this happens

Last night I disconnected my wifi access points (Ubiquiti Unifi APs) and I was able to stream reliably all night long. This appears to be the next area of investigation. Maybe the Access Points or some device on the access points is causing an impact. Any ideas on how to trouble shoot this as the next problem?

The hunt continues

Darron - what is this access point used for? Is it plug'n'play or does it assign its own IP addresses?

Adam

Ok Darron, if your new temp UPnP server PC was streaming local files, that is files on its drive and not coming from a remote NAS via a single switch to the Naim streamer and you have swapped the Ethernet leads over and the switch (which I think you say you have) then you are running out of options, and as I said earlier in such a case the most likely option now unfortunately is a suspect Naim streamer. Time to talk to your dealer or Naim support to get it checked and if appropriate repaired.

Simon

@ Adam : The Uniquiti Unifi access point is used for the wifi in my home. They are installed to provide broader coverage as an alternative to the ones built into my router (that is turned off). They connect to the central switch. They do have the ability to do their own DHCP. I'm going to turn that off and see if that helps. No other devices in my network are exhibiting issues.

@ Simon: I've already had the unit in to the dealer and then distributor for 6 weeks. They said they replaced some ribbon cables and tightened some others. If I don't have any luck with the Access Points, they offered to let me try an NDX (though if it is using the same networking hardware we may see the same issues if the root is the resiliency of the Naim networking hardware/firmware). Good option to try none the less.

Darron Stepanich posted:

@ Adam : The Uniquiti Unifi access point is used for the wifi in my home. They are installed to provide broader coverage as an alternative to the ones built into my router (that is turned off). They connect to the central switch. They do have the ability to do their own DHCP. I'm going to turn that off and see if that helps. No other devices in my network are exhibiting issues.

@ Simon: I've already had the unit in to the dealer and then distributor for 6 weeks. They said they replaced some ribbon cables and tightened some others. If I don't have any luck with the Access Points, they offered to let me try an NDX (though if it is using the same networking hardware we may see the same issues if the root is the resiliency of the Naim networking hardware/firmware). Good option to try none the less.

Darron - if you have multiple devices trying to assign IP addresses (Uniquiti and your Broadband modem) we may have found a culprit. I found, from my own expeience, that when two devices had that capability, the network would function ok, but streaming services would be rendered nigh impossible.

Can you please do the following:

* Unplug the Uniqiti Access point from your network and re-set your main broadband modem. This will force the network to re-learn itself.

* Try streaming like that for 48 hours

* For network extensions, if you already have Apple Airport Extreme I recommend other Apple devices

Adam

Darron Stepanich posted:

@ Adam : The Uniquiti Unifi access point is used for the wifi in my home. They are installed to provide broader coverage as an alternative to the ones built into my router (that is turned off). They connect to the central switch. They do have the ability to do their own DHCP. I'm going to turn that off and see if that helps. No other devices in my network are exhibiting issues.

@ Simon: I've already had the unit in to the dealer and then distributor for 6 weeks. They said they replaced some ribbon cables and tightened some others. If I don't have any luck with the Access Points, they offered to let me try an NDX (though if it is using the same networking hardware we may see the same issues if the root is the resiliency of the Naim networking hardware/firmware). Good option to try none the less.

Darron, perfect, try that loan NDX.. that's going to help diagnose this far more quickly. On a simple home network this stuff normally just works with no fuss. If I was to be critical of the Naim products, there is a lack of diagnostics for the occasional time things don't go to plan... normally this would help pin things down far quicker with a support call, and far more effective than this trial and error approach.

Simon

As I posted earlier I had some issues with an ND5 but ever since it has been in its new home within 2 feet and hard wired into the BT hub which in turn is about a foot from the internet inlet I have had no dropouts at all not one but the NDS and my BT you view box are the only two things hard wired into the network so maybe that helps too.

If you've got more than one DHCP server in your network then you don't stand an earthly chance of it all working correctly.   Take a very close look at this as a priority !

Darron Stepanich posted:

Latest update:

 

Last night I disconnected my wifi access points (Ubiquiti Unifi APs) and I was able to stream reliably all night long. This appears to be the next area of investigation. Maybe the Access Points or some device on the access points is causing an impact. Any ideas on how to trouble shoot this as the next problem?

The hunt continues

This was PRECISELY my issue.  I use an Apple Airport Extreme / Time Capsule as a wifi access point, and it was what was causing the same type of buffer-emptying dropouts you report.  Add them back one at a time and find the culprit. Do a factory reset on it, to see if that works. Or throw it the f out.

(A factory reset fixed my issue and the device is still in my network and behaving just fine.)

*EDIT*  TURN OFF DHCP ON THOSE WIFI ACCESS POINTS.  There is no way this stuff will work with multiple ip ranges on one network.  

There is a setting turn off dhcp from the unify controller. I did this but still seeing dropouts after this change ( I powered off router and switches after this and then turned on to relearn network).

There are also settings for each wireless access point to connect via dhcp or static ip. I assume we want to continue to use dhcp here so the main router defines the address.

Assuming this is correct....im still stuck with this issue. I might try a reset of the unifi aps and try again.

Ive also opened a question on the unifi newsgroups to see if anyone there has suggestions on how to troubleshoot. Let's hope there are some awesome contributors like there are on this forum! 

http://community.ubnt.com/t5/U...m-p/1634602#U1634602

I would try using a DHCP finder tool to see if you have any rogue DHCP servers on your network... Seem to be a few to choose from on the net depending on your level of trust/expertise. 

If nothing else at least you'll know if you have an unexpected DHCP device somewhere. You now appear to have several devices that can perform that role... (Apple, Ubiquiti... ) 

Once you have that verified, I would also search for any devices that might have a static address defined by mistake. 

Thanks for the suggestion. I will give that a try tonight.

I've been still troubleshooting with a bunch of people on the Unifi forums. Some suggested a sonos network loops ( I removed all Sonos devices but didn't help) and some suggesting a potential broadcast storm (I'm going to try a switch tonight that supports STP protocol to see if that helps eliminate a potential issue there). Been through a half a dozen other potential ideas but no luck yet....still get a network dropout on the ND5 XS when my Wifi gets turned on/plugged into the central switch.

I'll keep plugging. Going to pick up the NDX too and see if that makes any difference.

Tried the dhcp discovery tool. Only see my main router....so looks ok.

Packet from 192.168.1.1
 Offered IP 192.168.1.55
 Lease Length 86400 Seconds
 Renew Due in 43200 Seconds
 Subnet Mask 255.255.255.0

http://www.symantec.com/connec...dhcp-servers-network

I thought the issue was dropouts? DHCP is nothing to do with that what so ever.. If DHCP was not working correctly, there would be nothing to dropout from in the first place. If there was a network loop then firstly almost impossible to set up without knowing on a single setup which we should have by now, and the network would almost instantly grind to a halt. The simple ARP initialisations would collapse. Spanning Tree Protocol is usually only used in managed pro network equipment and is used to manage layer 2 resilience/redundancy. The Sonos uses its own implementation of Spanning Tree because of the way it can work with the existing wifi and its own wifi in parallel... so is specific to that product.

it probably is best for the OP to be a little structured, I think we are waiting to hear if the loan NDX works in situ as we have been told everything else has been swapped and / or replaced so is the last remaining item if rthe above posts are accurate.

if the replacement NDX is then also having problems the OP should build a little dedicated seperate network from scratch and add to it until the issues reoccur...

Simon

Thanks Simon. Yes, dropout is the issue. I'm trying any suggestions at this point, but thanks for clarifying.

I've got some firmware updates from the Access Point manufacturer I'm running through a test tonight to see if any impact/improvement to rule that out. Then will get the NDX if still reproducing it.