Sonicorbiter - NAA Output Mode

[mf22433]

Any other user here that can confirm changing a switch made the MicroRendu not loosing network connection ?

 

See my reply above, a setup with Sonicorbiter (software is the same as microrendu) which does not work without any switch involved.

[mf22433]

See my reply above, a setup with Sonicorbiter (software is the same as microrendu) which does not work without any switch involved.

 

HQP/NAA setup not working because the Sonicorbiter itself works perfectly when in Roon mode...

I still think the issue is related to HQP/NAA.

[mwhitak]

See my reply above, a setup with Sonicorbiter (software is the same as microrendu) which does not work without any switch involved.

 

I have the HQP/NAA problem (see my earlier posts) with no switch in the setup. Everything (Microrendu, PC) wired direct to modem/router. I can run Wireshark (promiscuous mode helping ?) and get HQP to finally see the Microrendu, however, it's not persistent (Wireshark must be started). Wireshark can be shut down at this point, and the communications are still present and working.....but on a restart of the PC, the communications is lost, and one must start up Wireshark and initiate a capture all over again to re-establish the connection.

[JohnSwenson]

Yesterday and today I have been running a bunch of tests with HQP and microRenu running NAA mode. I have tried several different computers and OSes to run HQP, a bunch of different switches and routers.

 

Most of the configurations work fine, there is one configuration that fails:

 

If the path from the computer HQP is running on to the microRendu goes through a managed Cisco switch, HQP will not discover the NAA on the microRendu.

 

Note that an unmanaged Cisco switch works fine (I have a SG-100-08). It is the managed types (SG-200 or SG-300) that have the problem. For this post I'm going to call the managed switch a CMS (Cisco Managed Switch).

 

You can have a CMS on your network, just as long as the path from HQP to NAA does not go through it. It doesn't matter what switch the computer or NAA is connected to as long as the path between them does not go through the CMS.

 

Other switches will be called SWA, SWB, SWC etc.

The computer HQP is running on will be called HQP, the microRendu in NAA mode will be called NAA.

 

Some example that will NOT work:

 

HQP and NAA both connected to CMS.

SWA connected to CMS, HQP connected to CMS, NAA connected to SWA. Opposite connection will also not work, NAA on CMS, HQP on SWA.

 

SWA connected to CMS, SWB connected to CMS, HQP on SWA, NAA on SWB.

 

What DOES work:

 

SWA connected to CMS, both HQP and NAA connected to SWA.

SWA connected to CMS, SWB connected to SWA, HQP connected to SWA, NAA connected to SWB

 

The above is pointing to the mechanism used by HQP to discover NAAs is not properly passing through the CMS, but does pass through other witches properly. My guess is that it is UDP multicast. The squeezebox system uses UDP multicast for it's discovery system so I also tried putting the microRendu into squeezelite mode and tried the above tests and got exactly the same results. I then tried an SB Touch, when connected to a CMS it took about three minutes to connect to LMS. When connected to another switch it took a couple seconds.

 

This seems to point to the underlying issue being that CMS does not pass UDP multicast properly. At this point I am not sure if CMS is not passing it at all, or maybe something like taking a long time to pass it causing timeouts. Given that the SBT did eventually connect it seems like it might be a timing issue, that the CMS does pass the UDP multicast, but with a long delay which causes software to usually timeout. If things are right on the edge the successful discovery might depend on how many times the multicast is sent out.

 

Now on to connecting direct to routers. This may or may not work. SOME routers DO have problems with UDP multicast, if yours does you may have the same issues with router as with a CMS. If you DO have a CMS and have problems connecting, you might want to try connecting both HQP and NAA to the router switch, it might work. Many routers are perfectly fine with UDP multicast. For example all the ones I had on hand to try worked fine with HQP and NAA. I DID have a router a long time ago that did not pass UDP multicast on its switch.

 

The next round of tests is going to be running wireshark and see if this is in fact UDP multicast and if it is timing or just not passing it. After that is to try and see if there is some configuration of the switch that can alleviate the problem.

 

John S.

[Jud]

The next round of tests is going to be running wireshark and see if this is in fact UDP multicast and if it is timing or just not passing it. After that is to try and see if there is some configuration of the switch that can alleviate the problem.

 

John S.

 

John, there's a bunch of stuff about this on the Web.

[Miska]

I have the HQP/NAA problem (see my earlier posts) with no switch in the setup. Everything (Microrendu, PC) wired direct to modem/router. I can run Wireshark (promiscuous mode helping ?) and get HQP to finally see the Microrendu, however, it's not persistent (Wireshark must be started). Wireshark can be shut down at this point, and the communications are still present and working.....but on a restart of the PC, the communications is lost, and one must start up Wireshark and initiate a capture all over again to re-establish the connection.

 

This indicates problem with the network adapter or the driver.

 

In promiscuous mode the IP layer in OS handles all multicast subscriptions. In normal mode, typical ethernet interface has a hardware table for multicast subscriptions (side varies) and if the table becomes full, the driver/OS takes over and the hardware table is disabled. When driver or OS handles subscriptions, the hadware table is set to pass all multicast traffic and the filtering is done at the higher level. As long as the hardware table is sufficient (and works) it handles the multicast traffic filtering based on subscriptions and software will only ever know about packets that match the subscriptions.

 

However, this is one of the areas where there are lot of hardware/firmware/driver bugs and "features" because it is one of the "less" used functionality and manufacturers are not really careful on this area when they release networking products. However, many local network protocols rely on this functionality to operate correctly, such as UPnP, Bonjour/Avahi (for things like discovering network printers and AirPlay devices) and NAA...

[Miska]

HQP/NAA setup not working because the Sonicorbiter itself works perfectly when in Roon mode...

I still think the issue is related to HQP/NAA.

 

I belive the way Roon does the discovery is to just scan the entire class-C subnet by knocking at all of the 255 IP's on the network and see who responds. I prefer not to do network scanning... For starters, I don't want to rely that user is on class-C network and corporate networks would generally get upset by such scanning activities.

 

Sure, sort of "brute force" can make bad networks functional, but that just brushes the problems under the rug.

[Miska]

Note, NAA >= 3.4.0 and HQPlayer >= 3.14 uses extended discovery, so in addition to IPv6 support, there's a two-layer discovery now. This may help in some cases.

[Miska]

thus have here HQP/NAA that does not work without any switch (Cisco or other) in the loop.

 

It should kind of work without switch, there is no requirement for a switch per se, but the issue arises more from the cases where the HQPlayer machine is "multi-homed", meaning having multiple network interfaces. In such cases you need to make sure multicast routing actually puts traffic towards the NAA link and not just towards the one typically facing internet. If the traffic goes to just one adapter (the default route - internet one) there is a problem if NAA is on the other adapter.

[JohnSwenson]

John, there's a bunch of stuff about this on the Web.

 

So I went into the switch and changed the multicast mode to 'forward all" for the audio VLAN and now everything is working great.

 

The documentation for the switch says that in forward all mode multicast is handled by the switch hardware so happens very quickly. In any other mode the processor has to handle all multicast traffic (to figure out what to do with it) which slows it down.

 

HQP and microRendu is now working in any configuration I could setup.

 

John S.

[vortecjr]

Thanks guys for pitching in on this issue.

[mf22433]

So I went into the switch and changed the multicast mode to 'forward all" for the audio VLAN and now everything is working great.

 

The documentation for the switch says that in forward all mode multicast is handled by the switch hardware so happens very quickly. In any other mode the processor has to handle all multicast traffic (to figure out what to do with it) which slows it down.

 

HQP and microRendu is now working in any configuration I could setup.

 

John S.

 

Dear John, on my Cisco SG 200-18 I just set the multicast forward all setting to "static" for all individual ports (the factory default settings were set to "none", see picture below) ... and HQP is now working either stand-alone or with Roon !

 

That was the trick indeed. Thanks for your help !

 

[vortecjr]

Dear John, on my Cisco SG 200-18 I just set the multicast forward all setting to "static" for all individual ports (the factory default settings were set to "none", see picture below) ... and HQP is now working either stand-alone or with Roon !

 

That was the trick indeed. Thanks for your help !

 

[ATTACH=CONFIG]29175[/ATTACH]

 

Nice! I just added the symptom and the fix to the Knows Issues post: http://www.computeraudiophile.com/f26-sonore-sponsored/sonicorbiter-known-issues-28651/

[vortecjr]

I've searched around and can't seem to find and answer to my situation. I am running a powerful Win7 machine (dual quadcore with Xeon processors and 128 GB RAM) with a RAID5 setup for my music library, and have Roon on that machine. I've been able to set up MicroRendu with no issues when using Roon directly (no HQ Player), but have issues when trying to set up to run with HQ player. Specifically, the issue is related to the music files getting played back 'quickly' - like fast forwarding while playing. The DAC's I use are PCM only, and one is limited to 24/192 (Empirical Audio OverDrive SE), and the other is limited to 24/96 (Lavry DA2002, fed with an Empirical Audio OffRamp 5). Any tips on how I can resolve this?

 

Let's see what rate you are actually playing. Start playback of some content with a known rate and then go to Apps / DAC Diagnostics in the GUI and see what the momentary frequency is. FYI you have to refresh the page when you change the content being played. Also, have a look at my HQ Player how to guide for proper settings: http://www.computeraudiophile.com/f26-sonore-sponsored/signalyst-hq-player-101-a-29494/

[R1200CL]

So I went into the switch and changed the multicast mode to 'forward all" for the audio VLAN and now everything is working great.

 

The documentation for the switch says that in forward all mode multicast is handled by the switch hardware so happens very quickly. In any other mode the processor has to handle all multicast traffic (to figure out what to do with it) which slows it down.

 

HQP and microRendu is now working in any configuration I could setup.

 

John S.

 

Thanks John for your effort to find a solution so quick.

Hopefully this will stop my connections problems as well. Updated firmware for my Cisco switch last week. Now just did the forward multicast.

So far only one stop of music. Will report back later if problems still exist.

[R1200CL]

Dear John, on my Cisco SG 200-18 I just set the multicast forward all setting to "static" for all individual ports (the factory default settings were set to "none", see picture below) ... and HQP is now working either stand-alone or with Roon !

 

That was the trick indeed. Thanks for your help !

 

[ATTACH=CONFIG]29175[/ATTACH]

 

If I understand the user manual correctly you will have to do one more thing:

"The Forward All page enables configuring the ports and/or LAGs that are to receive Multicast streams from a specific VLAN. This feature requires that Bridge Multicast filtering in the Properties page be enabled. If it is disabled, then all Multicast traffic is flooded to ports in the device."

 

http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/Cisco_300Sx_v1_4_AG.pdf

 

I'm not sure if this solution help my situation. I loose connection with the MicroRendu, and you was not able to be able to see the NAA software on a PC. Right ?

 

I just lost connection again, so this solution may not helped my case.

 

Also I think you need to add "Multicast Router Port"

But I may be wrong.

[JohnSwenson]

If I understand the user manual correctly you will have to do one more thing:

"The Forward All page enables configuring the ports and/or LAGs that are to receive Multicast streams from a specific VLAN. This feature requires that Bridge Multicast filtering in the Properties page be enabled. If it is disabled, then all Multicast traffic is flooded to ports in the device."

 

http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/Cisco_300Sx_v1_4_AG.pdf

[ATTACH=CONFIG]29236[/ATTACH]

 

I'm not sure if this solution help my situation. I loose connection with the MicroRendu, and you was not able to be able to see the NAA software on a PC. Right ?

 

I just lost connection again, so this solution may not helped my case.

 

Also I think you need to add "Multicast Router Port"

[ATTACH=CONFIG]29237[/ATTACH] But I may be wrong.

 

In my case I WANT the disabled setting, this passes the multicast packets through the switch hardware, bypassing the CPU. If it is enabled, multicast packets go into the CPU which figures out what to do with them, this process takes much more time than going through the dedicated switch hardware, for me this seemed to be the problem.

 

Note that the multicast packets are only used for discovery NOT playing music, so there will not be any large amount of extra traffic on other VLANs. So the fact that it "floods all ports" should not be a particular issue, a couple packets a day that are ignored by everything other than HQP or an NAA should not be a problem.

 

Now if you have ANOTHER application that is constantly sending out large numbers of multicast packets on a specific VLAN that you don't want to show up on other VLANs, then this might not be a good solution.

 

John S.

[R1200CL]

In my case I WANT the disabled setting, this passes the multicast packets through the switch hardware, bypassing the CPU. If it is enabled, multicast packets go into the CPU which figures out what to do with them, this process takes much more time than going through the dedicated switch hardware, for me this seemed to be the problem.

 

Note that the multicast packets are only used for discovery NOT playing music, so there will not be any large amount of extra traffic on other VLANs. So the fact that it "floods all ports" should not be a particular issue, a couple packets a day that are ignored by everything other than HQP or an NAA should not be a problem.

 

Now if you have ANOTHER application that is constantly sending out large numbers of multicast packets on a specific VLAN that you don't want to show up on other VLANs, then this might not be a good solution.

 

John S.

 

OK. And thanks. Let's assume my problems are a bit different then. (Anyway I edited my switch back to suggested settings.)

 

Is it a normal or correct behavior that to reset the HQPlayer, it will take fist close to a minute, then an Error 500, and then finally after an other 30 seconds this page finally appear:

In addition I have to open settings in HQPlayer in order to remove the error message that Roon lost control of the network player/device. According to Miska this shall not be necessary to do.

 

After a reboot, or in a state that Roon has not lost connection, the reboot HQPlayer (in MicroRendu) takes only a few seconds. Why the difference ?

 

Any suggestion how best to proceed ?

 

Edit other settings in the Cisco switch ?

Bypass the switch temporary, by using my Asus RT-AC66U (in AP mode) that only purpose is to act as the wireless interface for iPads etc. ?

[vortecjr]

OK. And thanks. Let's assume my problems are a bit different then. (Anyway I edited my switch back to suggested settings.)

 

Is it a normal or correct behavior that to reset the HQPlayer, it will take fist close to a minute, then an Error 500, and then finally after an other 30 seconds this page finally appear:

[ATTACH=CONFIG]29248[/ATTACH]

In addition I have to open settings in HQPlayer in order to remove the error message that Roon lost control of the network player/device. According to Miska this shall not be necessary to do.

 

After a reboot, or in a state that Roon has not lost connection, the reboot HQPlayer (in MicroRendu) takes only a few seconds. Why the difference ?

 

Any suggestion how best to proceed ?

 

Edit other settings in the Cisco switch ?

Bypass the switch temporary, by using my Asus RT-AC66U (in AP mode) that only purpose is to act as the wireless interface for iPads etc. ?

 

I'll leave the switch questions up to John.

 

All that button does is restart NAA on the microRendu. It's a website so how long it takes to reload is up to the network. It's pretty fast here though.

[Miska]

In addition I have to open settings in HQPlayer in order to remove the error message that Roon lost control of the network player/device. According to Miska this shall not be necessary to do.

 

When you hit play again in Roon, it will regain control of HQPlayer. But the way it works is that if you touch HQPlayer GUI while Roon is playing, it assumes you want to take over control of HQPlayer. Same happens also if connection to NAA is lost and as a result HQPlayer stops playback. Roon sees this and releases control.

 

Next time you hit play in Roon, it tries to control HQPlayer again and if the NAA connection was lost, HQPlayer will try to connect to the NAA again.

[R1200CL]

All that button does is restart NAA on the microRendu. It's a website so how long it takes to reload is up to the network. It's pretty fast here though.

 

Very interesting. Then one issue could be that something on my local network slow down that connection. How to find that something, and is that something part of me loosing connection...

 

Or there is an issue with SW (or HW?) inside the MicroRendu. It's hard to believe there can be some general error, since I may be the only one reporting this type of behavior. Test another unit man not be a solution yet ?

 

Under normal conditions, my MicroRendu is very fast, it's after the losing connection it either need restart, or use this very long time to respond to restarting the HQPlayer NAA. Also it's only the NAA mode that is slow. I can access the rest of the MicroRendu very quickly.

 

Any help in this information ?

[R1200CL]

Next time you hit play in Roon, it tries to control HQPlayer again and if the NAA connection was lost, HQPlayer will try to connect to the NAA again.

 

Well I'm sure it's trying, but it is not succeeding. Have to open settings and press OK. BUT only after a lost connection situation.

 

I just did a test and reboot my MicroRendu. First stopped playing. Reboot. Press play in my iPad app, and yes it played !

 

This tells us that reboot the NAA may be different from reboot the unit, but necessary not, cause I will first have to test a reboot unit after a lost connection has happen as well.

The difference is of cause I will not have pressed stop play first.

 

Also performed an other test. Press stop music. Reboot the NAA. Took long time as usual. Press play. Worked, music play !

 

Did also press restart NAA while music was playing. Then only after my pressing the second time did Roon lose control of the audio device. And this time as may expected, HQPlayer was not able to reconnect. This everyone can test. Should get the same result as me I guess.

 

And now when I reboot the MicroRendo, afer creation this situation, music will not play until I open/close settings in HQPlayer.

 

Not sure if this gets us any closer to isolation the problem though. But obviously something blocking the communication on my network, and it seems to depending on this "thing" that make me loose connection.

[R1200CL]

I taught I may try to make my last posts a bit clearer.

 

If you stop music in Roon. (I'm using iPad interface)

You can reboot the MicroRendu or only the HQPlayer's NAA and you will have no problem with press play again without touching the HQPlayer SW itself. As it should do according to Miska.

 

In my case restart the HQPlayer's NAA in the MicroRendu web interface takes normally close to one minute. Then the Error 500 display, and a refresh of around 30 seconds is needed in order to get the green confirmation that HQPlayer is restarted.

If other people get's a fast response here, I guess we may be closer to point at my local network, or my MicroRendu.

It seems I can only have a fast reboot of HQPlayer's NAA after a reboot of the MicroRendu itself. (Then two seconds)

 

If you do any of this reboot/restart while music is playing, which you may say is a odd thing to do, HQPlayer's NAA will not be able to establish connection with HQPlayer.

This should be a test most people can do. And hopefully you get the same result as me ?

 

Miska:

My finding with reboot during playback is not according to how you describes things are supposed to be working or ?

 

Can you or John think of any "Network Demon" that will cause your NAA sw to make the Roon loose connection with the audio device ?

 

I'm using HQPlater 3.14beta8

[Miska]

If you stop music in Roon. (I'm using iPad interface)

You can reboot the MicroRendu or only the HQPlayer's NAA and you will have no problem with press play again without touching the HQPlayer SW itself. As it should do according to Miska.

 

Have you made sure Roon has actually stopped HQPlayer before doing reboots or other stuff? Normally Roon first just pauses HQPlayer (means HQPlayer is playing back silence) and then after 10 seconds stops HQPlayer.

 

Miska:

My finding with reboot during playback is not according to how you describes things are supposed to be working or ?

 

If you reboot while playback is ongoing bad things will happen. Especially if you do something like unplugging DAC on the fly while it is playing. You will very likely have trouble after doing that. It is like stepping out of the car while going 100 km/h.

 

If you do things when HQPlayer is in stopped state, things should work.

 

Can you or John think of any "Network Demon" that will cause your NAA sw to make the Roon loose connection with the audio device ?

 

If there's a connection loss between HQPlayer and NAA, HQPlayer will report that playback went down and Roon will conclude that it was a stop action it didn't ask for and let loose of the HQPlayer. Next time you attempt to start playback in Roon it will re-establish HQPlayer control.

 

If you do actions on the HQPlayer GUI or something else happens that Roon didn't ask for, Roon will detach from HQPlayer to avoid competing with you at the HQPlayer side.

 

I'm using HQPlater 3.14beta8

 

You should update to final 3.14...

[R1200CL]

When you hit play again in Roon, it will regain control of HQPlayer. But the way it works is that if you touch HQPlayer GUI while Roon is playing, it assumes you want to take over control of HQPlayer. Same happens also if connection to NAA is lost and as a result HQPlayer stops playback. Roon sees this and releases control.

 

Next time you hit play in Roon, it tries to control HQPlayer again and if the NAA connection was lost, HQPlayer will try to connect to the NAA again.

 

My problems are still the same after upgrade to latest HQPlayer version yesterday.

Things does not work as you describe it. HQPlayer are not able to connect to HQPlayer NAA 3.4 in the MicroRendu. Does there exist a logfile for the NAA ?

 

Since you make both the SW that does not work as I'm hoping you could find time to look into this.

 

It may happen I have a HW error, like a second power loss in my MicroRendu or the hiFace EVO USB/SPDIF converter, but still if I understand your description correctly, your SW should be able to re establish connection, right ?

 

I have ordered this product https://www.amazon.com/gp/product/B017SOXP1Q/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1to see if I can detect some loss of power. Not sure it will fulfill that task.

 

http://www.droking.com/wp-content/uploads/2016/06/Instruction_180055.jpg

 

The idea is the the run time function will stop if a power loss is happening. Probably a long shot. Don't even know if it a good idea to connect it between the MicroRendu and the hiFace.

 

EDIT:

Did not see your last answer before I wrote this post.