Sonore opticalModule v0.95 - discontinued

[Foggie]

/\ /\  Would also be beneficial to indicate this potential issue in the literature (maybe it already is). 

 

I will test a couple things previously pointed out but doubt any of those will solve the issue without the “bandaid”.  I’ll also try mU as just a Roon endpoint 

 

 I wasn’t aware about the specific “flow control issue” within the mU device that was just mentioned.  Good that the OR has that built in so to speak and not reliant on end users switches / enviro 

[sgb]

On 9/6/2019 at 9:37 AM, Foggie said:

/\ /\  Would also be beneficial to indicate this potential issue in the literature (maybe it already is). 

 

I will test a couple things previously pointed out but doubt any of those will solve the issue without the “bandaid”.  I’ll also try mU as just a Roon endpoint 

 

 I wasn’t aware about the specific “flow control issue” within the mU device that was just mentioned.  Good that the OR has that built in so to speak and not reliant on end users switches / enviro 

For me the opticalModule worked with ultraRendu and the Roon endpoint. The problem only occurred with HQP as endpoint. And, no I didn't either find any information about this limitation.

[Foggie]

So I updated mU and then powered off and rebooted the entire chain, no go.  I'll speak with Sonore offline as they have always been great at assisting and communicating with.

[JohnSwenson]

Hi All,

the issue with NAA is somewhat complicated, so I'll try and explain it so it is easy to understand.

 

Most protocols have an explicit "flow control", the server needs some way to send the data at some rate that doesn't overflow the DAC. The NAA protocol doesn't seem to do this, it seems to rely on a very low level mechanism built in to Ethernet called pause frames. If the receiver's buffer is getting too full it sends a pause frame upstream. The switch sending the data then stops sending data. The problem with this is that this is handled by the network equipment, not the source of the data, HQP.

 

There are some generic issues here, network professionals hate pause frames, it's very easy for a network  to go into gridlock because of pause frames. The result is that almost all "profesional" switches, which are usually managed switches, do not by default handle pause frames, you have to explicitly turn them on. "Home" routers usually do support pause frames.

 

The issue with the oM is that the circuit inside is NOT a switch, thus it cannot handle pause frames, it passes them on up stream, but it by itself cannot pause the stream. The problem here is that the linux kernel inside of the Rendus asks the connected device if it supports pause frames, the oM says no it cannot (which is the correct response), so the linux never sends any pause frames when its buffers fill up. The problem is that it SHOULD send them because the oM will send them right along to the upstream switch which CAN deal with it. 

 

We found this issue in the opticalRendu development and found a fix for it, it causes the linux kernel to go ahead and send the pause frames even when the oM says it cannot handle them. This has gone out in every oR sold. It was supposed to be added to the software for the other rendus, but I'm not sure if it actually made it.

 

So if you guys are having the problem with NAA and an oM on an ultrRendu or microRendu try doing an update (you have to be at 2.7 for this to work) and see if that fixes the problem.

 

Note this is only going to work if the upstream switch properly handles pause frames. If you have a managed switch you may need to explicitly turn on pause frames to use NAA (whether there is an oM involved or not).

 

I hope this helps clarify the situation.

 

John S.

 

 

[vortecjr]

On 9/6/2019 at 1:56 PM, JohnSwenson said:

It was supposed to be added to the software for the other rendus, but I'm not sure if it actually made it.

John it has not and we need to push it into the other Rendu's. We are planning to do this very soon.

[Foggie]

Thanks @JohnSwenson for the info. 

 

OK so it sounds like until a software fix is added to earlier rendu's to support this issue, the only solution that "might" work is to either use a dumb switch (which defeats the entire purpose) or enable flow control on a managed switch?

 

FWIW here are my flow control settings.

[Foggie]

Curious and if you can => In simple terms, why does the Trendnet FMC 10/100/1000 handle this situation but the OM and TPlLink FMC's (MC220L I think) don't handle this?

[JohnSwenson]

A switch can deal with the pause frames. The FMCs are theoretically very simple devices, just converting from one network form to another without doing anything to the data. 

 

It depends how the designer of the FMC implemented it. If the FMC uses a switch, then it will handle the pause frames, if a switch was NOT used it won't handle the pause frames.

 

For the oM I deliberately chose to use a very simple circuit, a switch chip does a whole lot more causing significantly more ground plane noise etc. I wanted the oM to be as pristine as possible so I left out stuff it didn't need. (switch chips also use quite a bit more power)

 

Other designers will make different decisions on this.

 

John S.

 

 

[dminches]

Are this flow control issues limited to fiber optic?  If not, why don't people have these issues when just going ethernet to a microRendu?

 

[The Computer Audiophile]

Just now, dminches said:

 

Are this flow control issues limited to fiber optic?  If not, why don't people have these issues when just going ethernet to a microRendu?

 

Nothing to do with fiber. I reported a similar issue years ago with Roon and several devices. 

[dminches]

Just now, The Computer Audiophile said:

Nothing to do with fiber. I reported a similar issue years ago with Roon and several devices. 

 

Thanks.  Hopefully this means that if I move from my ultraRendu to an oM plus opticalRendu I won't have issues since my current setup doesn't.

 

[Superdad]

6 minutes ago, dminches said:

Are this flow control issues limited to fiber optic?  If not, why don't people have these issues when just going ethernet to a microRendu?

 

Please carefully re-read John's detailed post about it:

https://audiophilestyle.com/forums/topic/55862-sonore-opticalmodule/?do=findComment&comment=988007

[dminches]

I did but it isn't 100% clear. 

 

First, John says "We found this issue in the opticalRendu development."  Why wasn't this seen with the micro or ultra?  This comment led me to wonder if this was fiber-related.  I realize now it isn't.

 

Second, I didn't understand what the oM had to do with this.  It is part of the discussion but it seems like the oM is just passing data.

 

This is why I asked my question.

 

[sgb]

If this problem when running NAA protocol, that the OM dosn't support pause frames when my ultraRendu asks, was a known problem why wasn't  I informed about this problem before i bought the OM. It could have saved me a lot of money.

 

I have tried both a unmanaged switch that have the IEEE 802.3x (Flow contol) protocol and a managed where i enabled Flow control.

It dosn't help

[vortecjr]

9 hours ago, dminches said:

 

Thanks.  Hopefully this means that if I move from my ultraRendu to an oM plus opticalRendu I won't have issues since my current setup doesn't.

 

You won't have this issue.

[vortecjr]

On 9/7/2019 at 3:09 AM, sgb said:

If this problem when running NAA protocol, that the OM dosn't support pause frames when my ultraRendu asks, was a known problem why wasn't  I informed about this problem before i bought the OM. It could have saved me a lot of money.

 

I have tried both a unmanaged switch that have the IEEE 802.3x (Flow contol) protocol and a managed where i enabled Flow control.

It dosn't help

The opticalModule does not need to support flow control because it just passes the request along. As discussed above the micro/ultraRendu are not requesting it yet.

[vortecjr]

On 9/7/2019 at 8:32 PM, JohnSwenson said:

This is not specifically an optical "thing", it is a combination of several things: NAA uses pause frames for flow control, linux assumes that all network devices a linux computer will be connected to are switches and the opticalModule is NOT a switch.

 

The use of pause frames is quite rare so most developers have never had to deal with them so it is not something that is normally even thought about. FMCs are one of the few device classes that is an Ethernet device but does not have to be a switch. So it turns out that some can handle pause frames and others cannot. I don't think this is a conscious decision, designers (including me) are not even thinking about this, it just depends on the implementation of the chip they choose. Whether it handles pause frames or not is usually not even in the data sheets.

 

It CAN happen without optical if you have a managed switch and you have not turned on pause frames. Again, this just applies to NAA.

 

This might also show up an any other situation where the network port of the Rendu is not connected to a switch, such as the "bridged" situation where the Rendu is connected directly to a computer, this sort of connection may or may not handle pause frames.

 

This showed up with the prototype of the oM, it took quite some time to figure out what was actually happening, I wasn't even thinking that one of the audio protocols required pause frames. This is not something that is published about NAA. I did come up with a software fix and it was applied to the oR so using the oM with the oR has worked for all oRs shipped. I thought this was also going into the other Rendus but that doesn't seem to have happened quite yet. When this is available it should fix the issue for all the Rendus. Just update the software and the issue should go away.

 

John S.

Typically, we push all the code into every version of Sonic Orbiter, but in this case we have been working on the next version of Sonic Orbiter and the push just hasn't happened yet. 

 

One of the cool things about Sonic Orbiter, which others have copied, is that there are several output protocols and the end user can decide which protocol they prefer. I don't fault NAA for this approach and I actually encourage it because it creates diversity. Jussi has expressed to me his reasons for this approach and I support him 100% on his goals.

 

Also, I think people don't understand our internal process when things like this come up. When we noticed the issue myself, John, and Andrew stopped what we were doing and each us started research, testing, and implementation efforts for the code. BTW I don't mean just one solution, I mean several solutions to back each other up. This is something that comes up from time to time and even though it's not a wide spread issue we are very close to making it go away completely. Understand that we have a lot of gear in the wild and our goal is to keep these units playing perfectly!

[jabbr]

I agree that having the Rendu implement flow control through standards (pause-frames) is the ideal solution.

 

Regarding this thread, is there a concern that non-Rendu low powered devices when used with the OpticalModule, won’t send pause-frames because the OpticalModule says it doesn’t support?

[vortecjr]

No real concern because the devices supported would be 1000 speed.  

[jabbr]

On 9/8/2019 at 4:47 PM, vortecjr said:

No real concern because the devices supported would be 1000 speed.  

 

I mean what about another low powered endpoint eg one of the Solid Run cubes or anything similar which can’t handle full 1g and would need to send out pause-frames. 

 

If using the opticalModule would that device (or similar generic) fail to send pause-frames also?

[vortecjr]

19 minutes ago, jabbr said:

 

I mean what about another low powered endpoint eg one of the Solid Run cubes or anything similar which can’t handle full 1g and would need to send out pause-frames. 

 

If using the opticalModule would that device (or similar generic) fail to send pause-frames also?

If it's a DIY solution then they are responsible for the fix. If it's a professional solution then they are responsible for the fix. Just the same with all FMCs that are not switches inside it has to be dealt with correctly

[jabbr]

22 minutes ago, vortecjr said:

If it's a DIY solution then they are responsible for the fix. If it's a professional solution then they are responsible for the fix. Just the same with all FMCs that are not switches inside it has to be dealt with correctly

 

Ok and to be clear, this issue is not isolated to HQPlayer but uPnP/DLNA is subject as well.

 

This issue does not apply to all FMCs, for example: https://www.perle.com/products/10-100-1000-media-converters.shtml explicitly stars that it supports 802.3xy

[vortecjr]

On 9/8/2019 at 5:35 PM, jabbr said:

 

Ok and to be clear, this issue is not isolated to HQPlayer but uPnP/DLNA is subject as well.

 

This issue does not apply to all FMCs, for example: https://www.perle.com/products/10-100-1000-media-converters.shtml explicitly stars that it supports 802.3xy

This flow control discussions has been about NAA. 

 

To to be sure it needs to be tested.

[jabbr]

On 9/8/2019 at 6:09 PM, vortecjr said:

This flow control discussions has been about NAA. 

 

To to be sure it needs to be tested.

Try mounting a network drive / SMB

Play a DSD256 (or 512 if you have one) directly on a Rendu without the fix — and connected to an opticalModule..

[vortecjr]

48 minutes ago, jabbr said:

 

Ok and to be clear, this issue is not isolated to HQPlayer but uPnP/DLNA is subject as well.

 

This issue does not apply to all FMCs, for example: https://www.perle.com/products/10-100-1000-media-converters.shtml explicitly stars that it supports 802.3xy

Thinking more about this it could be that it uses a switch chip and really supports it or it could be that it passes the signal when the correct signal is sent upstream. So it could actually support it or it could pass it along and they call that support. The documentation would have to be very specific. Again, you would have to test it.