Jump to content
IGNORED

Optical Network Configurations


Recommended Posts

oP received yesterday! Tks Jesus and Andrew.

Using a Jameco PS (10$) and the sound is fantastic! I was not expecting such an improvement. It was used before my Cisco and also after connected directly to my uR. Not sure what In which position I prefer it.  Did not experience any problems whatsoever with HQPlayer. The uR connects to an OPPO 205. I haven’t done any software upgrade for at least 3 weeks, I guess.

Regards,

Jorge

Jensen VRD-iFF>Router>Rj45>opticalModule>
SFP>Buffalo2016>SFP>opticalModule >Rj45>

IZen Mk3>Rj45> Delock62619>Rj45>
etherRegen (Master Clock+ Mini-Circuits BLP)>SFP>opticalRendu>USB>IsoRegen>

USB>Phoenix>USB>OPPO 205 (Modded)>HMS “the Perfect Match”>Proac Tablette Reference 8 Signature.
 

Link to comment
1 hour ago, soares said:

oP received yesterday! Tks Jesus and Andrew.

Using a Jameco PS (10$) and the sound is fantastic! I was not expecting such an improvement. It was used before my Cisco and also after connected directly to my uR. Not sure what In which position I prefer it.  Did not experience any problems whatsoever with HQPlayer. The uR connects to an OPPO 205. I haven’t done any software upgrade for at least 3 weeks, I guess.

Regards,

Jorge

 

What is an oP? 

SERVER CLOSET (in office directly below living room stereo):NUC 7i5BNH with Roon ROCK (ZeroZone 12V on the NUC)>Cisco 2690L-16PS switch>Sonore opticalModule (Uptone LPS 1.2)>

LIVING ROOM: Sonore opticalRendu Roon version (Sonore Power Supply)> Shunyata Venom USB>Naim DAC V1>Witchhat DIN>Naim NAP 160 Bolt Down>Chord Rumor 2>Audio Physic Compact Classics. OFFICE: opticalModule> Sonore microRendu 1.4> Matrix Mini-i Pro 3> Naim NAP 110>NACA5>KEF Ls50's. BJC 6a and Ghent Catsnake 6a JSSG ethernet; AC cables: Shunyata Venom NR V-10; Audience Forte F3; Ice Age copper/copper; Sean Jacobs CHC PowerBlack, Moon Audio DIN>RCA, USB A>C. Isolation: Herbie's Audio Lab. 

Link to comment

Ohhh so sorry. It’s oM (optical module)

Jensen VRD-iFF>Router>Rj45>opticalModule>
SFP>Buffalo2016>SFP>opticalModule >Rj45>

IZen Mk3>Rj45> Delock62619>Rj45>
etherRegen (Master Clock+ Mini-Circuits BLP)>SFP>opticalRendu>USB>IsoRegen>

USB>Phoenix>USB>OPPO 205 (Modded)>HMS “the Perfect Match”>Proac Tablette Reference 8 Signature.
 

Link to comment
1 hour ago, soares said:

oP received yesterday! Tks Jesus and Andrew.

Using a Jameco PS (10$) and the sound is fantastic! I was not expecting such an improvement. It was used before my Cisco and also after connected directly to my uR. Not sure what In which position I prefer it.  Did not experience any problems whatsoever with HQPlayer. The uR connects to an OPPO 205. I haven’t done any software upgrade for at least 3 weeks, I guess.

Regards,

Jorge

My apologies. I was referring to oM (optical Module) and not oP.

Tks Charles!

Best,

 

Jorge

Jensen VRD-iFF>Router>Rj45>opticalModule>
SFP>Buffalo2016>SFP>opticalModule >Rj45>

IZen Mk3>Rj45> Delock62619>Rj45>
etherRegen (Master Clock+ Mini-Circuits BLP)>SFP>opticalRendu>USB>IsoRegen>

USB>Phoenix>USB>OPPO 205 (Modded)>HMS “the Perfect Match”>Proac Tablette Reference 8 Signature.
 

Link to comment
On 9/12/2019 at 2:00 PM, jabbr said:

Here is the device configured as an “FMC” ie fiber media converter. 

 

Just to be sure:

Would I be able to use the CRS305's single RJ45 port on the left to connect the router to my non-fiber ethernet modem? It is mentioned in the manual that this is mainly used for management purposes.

Or do I need to buy a RJ45 to SFP(+) connector/adapter like the one you seem to be using, and put that in an SFP port?

 

audio system

 

Link to comment
41 minutes ago, bodiebill said:

 

Just to be sure:

Would I be able to use the CRS305's single RJ45 port on the left to connect the router to my non-fiber ethernet modem? It is mentioned in the manual that this is mainly used for management purposes.

Or do I need to buy a RJ45 to SFP(+) connector/adapter like the one you seem to be using, and put that in an SFP port?

 

You need an RJ-45 SFP module. I will post some compatibilities when I have time to test but they can be had for $10-20 on eBay and $40 or so on Amazon

Custom room treatments for headphone users.

Link to comment
27 minutes ago, jabbr said:

 

You need an RJ-45 SFP module. I will post some compatibilities when I have time to test but they can be had for $10-20 on eBay and $40 or so on Amazon

 

Thanks, that would be helpful!

(My current Mikrotik 106-1c-5s does have a usable RJ-45 port in addition to 5 SFP ports, so I was not sure.) 

 

Does your endpoint have a fiber NIC? Or do you use RJ-45 for the last downstream bit?

In other words do you use the Mikrotik to convert fiber to RF-45 or the other way around?

I guess this matters for how much impact the 10GB Mikrotik has?

 

audio system

 

Link to comment
1 hour ago, bodiebill said:

 

Thanks, that would be helpful!

(My current Mikrotik 106-1c-5s does have a usable RJ-45 port in addition to 5 SFP ports, so I was not sure.) 

 

I am not sure you need to change to the 305.

 

My point, actually, is that people such as @JohnSwenson have stated in the past that upstream jitter gets passed downstream. I am saying that, at least with 802.3ae Clause 52 ie 10Gbe ... that the “stressed eye pattern” testing ensures that this isn’t the case! This concept was considered at least as far back as 2002 and ensured against with the very rigorous testing required for 10Gbe standards compliance. 

 

Quote

 

Does your endpoint have a fiber NIC? Or do you use RJ-45 for the last downstream bit?

In other words do you use the Mikrotik to convert fiber to RF-45 or the other way around?

I guess this matters for how much impact the 10GB Mikrotik has?

 

I use the SolidRun Clearfog Base with a SFP input ... also Intel & Solarflare NICs with Celeron boards as NAA ... the Celeron runs XXHE quite well also. 

 

I also have wireless NAA: a NUC, a Raspberry Pi4 etc.

 

I don’t use copper Ethernet input to my endpoints, and haven’t since this thread started.

 

The opticalRendu should be very suitable.

Custom room treatments for headphone users.

Link to comment

Curious how you think it might be best to power one of these: poe or with a linear power supply (which would be an HDPLEX 100 at 12V most likely)?

 

My thinking is ethernet out from the Cisco 2960 main switch into the Mikrotik console port, SFP out to an oM and microRendu,  SFP to an oM and Naim Unitiqute, and Roon NUC into a port with an SFP/RJ45. I already have some spare SFP cages, and it would definitely simplify some things and be cheaper than buying yet another oM for the office Unitiqute (currently bridged by a pair of cheap TP Link 110's). 

SERVER CLOSET (in office directly below living room stereo):NUC 7i5BNH with Roon ROCK (ZeroZone 12V on the NUC)>Cisco 2690L-16PS switch>Sonore opticalModule (Uptone LPS 1.2)>

LIVING ROOM: Sonore opticalRendu Roon version (Sonore Power Supply)> Shunyata Venom USB>Naim DAC V1>Witchhat DIN>Naim NAP 160 Bolt Down>Chord Rumor 2>Audio Physic Compact Classics. OFFICE: opticalModule> Sonore microRendu 1.4> Matrix Mini-i Pro 3> Naim NAP 110>NACA5>KEF Ls50's. BJC 6a and Ghent Catsnake 6a JSSG ethernet; AC cables: Shunyata Venom NR V-10; Audience Forte F3; Ice Age copper/copper; Sean Jacobs CHC PowerBlack, Moon Audio DIN>RCA, USB A>C. Isolation: Herbie's Audio Lab. 

Link to comment
2 hours ago, jabbr said:

 

You need an RJ-45 SFP module. I will post some compatibilities when I have time to test but they can be had for $10-20 on eBay and $40 or so on Amazon

 

I think you can, though I'm not totally sure of much of the terminology being thrown around here: From the Quick guide:

 

  • One Gigabit Ethernet port, suggested to be used for management (Supports Auto MDI/X so you can use

    either straight or cross-over cables for connecting to other network devices).

SERVER CLOSET (in office directly below living room stereo):NUC 7i5BNH with Roon ROCK (ZeroZone 12V on the NUC)>Cisco 2690L-16PS switch>Sonore opticalModule (Uptone LPS 1.2)>

LIVING ROOM: Sonore opticalRendu Roon version (Sonore Power Supply)> Shunyata Venom USB>Naim DAC V1>Witchhat DIN>Naim NAP 160 Bolt Down>Chord Rumor 2>Audio Physic Compact Classics. OFFICE: opticalModule> Sonore microRendu 1.4> Matrix Mini-i Pro 3> Naim NAP 110>NACA5>KEF Ls50's. BJC 6a and Ghent Catsnake 6a JSSG ethernet; AC cables: Shunyata Venom NR V-10; Audience Forte F3; Ice Age copper/copper; Sean Jacobs CHC PowerBlack, Moon Audio DIN>RCA, USB A>C. Isolation: Herbie's Audio Lab. 

Link to comment
7 minutes ago, charlesphoto said:

 

I think you can, though I'm not totally sure of much of the terminology being thrown around here: From the Quick guide:

 

  • One Gigabit Ethernet port, suggested to be used for management (Supports Auto MDI/X so you can use

    either straight or cross-over cables for connecting to other network devices).

 

A 305 is on its way to me, so I will try and post the results.

 

audio system

 

Link to comment
6 hours ago, jabbr said:

Also the datasheet for the iMX6 specifies pause-frames because the internal speed is capped at 400Mbs ... are the pause-frames generated by the hardware ie PHY and the device driver controls? Or does the driver generate the frames?

 

AFAIK, in most cases PHY advertises pause frame capabilities and deals with negotiation, but MAC is the the one that actually generates the pause frames - since it's the one owning the packet buffers. There is always orchestration between PHY and MAC (through MII) to deal with configuring such interactions and this is where the driver steps in (and Linux kernel internally abstracts this). Since driver code runs on the APU (CPU), it cannot properly deal with pause frames because for example in iMX6 case it is behind the slower link between MAC and CPU. So CPU cannot react properly to the upstream traffic it sees "after the fact", once it has traveled across the slow link. Overall, it cannot know when MAC is going to overflow the buffer. While MAC is always has up-to-date information being at the Ethernet side of the slower local bus link and the one that fills the packet FIFO.

 

There are now also newer standards (802.1Qbb) that support flow-control based on packet priority, so lower priority traffic can be put on hold if necessary and keep higher priority traffic flowing. This is important for cases where you have lot of intermixed traffic like between switches, and less important for cases like NAA where you usually anyway have just a one notable stream. These newer things are mostly supported by more fancy newer hardware. For example NAA connection attempts to utilize 802.1p type QoS/CoS that can benefit from such flow control categorization.

 

Even the cheapest integrated NICs for PCIexpress tend to include both QoS/CoS and flow control using the older more established standards, like the commonly used cheap Realtek 8111:

https://www.realtek.com/en/products/communications-network-ics/item/rtl8111g

You can see both 802.1p and 802.3x listed there. Plus hardware offload of various network checksumming operations. And also 802.3az (EEE) to keep power consumption low. So all the specs I list for NAA.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
2 hours ago, Miska said:

AFAIK, in most cases PHY advertises pause frame capabilities and deals with negotiation, but MAC is the the one that actually generates the pause frames - since it's the one owning the packet buffers. There is always orchestration between PHY and MAC (through MII) to deal with configuring such interactions and this is where the driver steps in (and Linux kernel internally abstracts this).

 

Thanks I am sure that’s correct.

 

So it’s the fec.c driver in the Linux kernel which handles the configuration based on the auto-negotiation, I.e enables/disables pause-frames for the iMX6?

 

In the case of the Mikrotik/PresteraDX, it runs either “RouterOs” or “SwOS” —- I use SwOS because I run this as a switch. see: https://vswitchzero.com/2019/05/15/mikrotik-crs309-1g-8sin/

 

In any case this is closed source because it’s not Linux based, but the fec.c driver for the iMX6 is open source... hmm ...

 

 

Custom room treatments for headphone users.

Link to comment

@JohnSwenson or @vortecjr (I don't know who is responsible for the driver)

 

 in:  https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/freescale/fec_main.c

 

static int fec_enet_set_pauseparam(struct net_device *ndev,
				   struct ethtool_pauseparam *pause)
{
	struct fec_enet_private *fep = netdev_priv(ndev);

	if (!ndev->phydev)
		return -ENODEV;

	if (pause->tx_pause != pause->rx_pause) {
		netdev_info(ndev,
			"hardware only support enable/disable both tx and rx");
		return -EINVAL;
	}

	fep->pause_flag = 0;

	/* tx pause must be same as rx pause */
	fep->pause_flag |= pause->rx_pause ? FEC_PAUSE_FLAG_ENABLE : 0;
	fep->pause_flag |= pause->autoneg ? FEC_PAUSE_FLAG_AUTONEG : 0;

	phy_set_sym_pause(ndev->phydev, pause->rx_pause, pause->tx_pause,
			  pause->autoneg);

	if (pause->autoneg) {
		if (netif_running(ndev))
			fec_stop(ndev);
		phy_start_aneg(ndev->phydev);
	}
	if (netif_running(ndev)) {
		napi_disable(&fep->napi);
		netif_tx_lock_bh(ndev);
		fec_restart(ndev);
		netif_tx_wake_all_queues(ndev);
		netif_tx_unlock_bh(ndev);
		napi_enable(&fep->napi);
	}

	return 0;
}

Is this were you modify the driver so that pause-frames are enabled for the xRendu despite not being advertised as supported on the opticalModule? I am trying to understand what the best practice is for this.

Custom room treatments for headphone users.

Link to comment
4 hours ago, bodiebill said:

 

No intrinsic need. But I expect it to lower jitter based on what I read in this thread.

 

Actually, I could keep the Miktotek 106-1c-5s and wire like:

modem => CAT7 => 106 => fiber => 305 => X520 => endpoint

or use an FMC instead of the 106.

 

 

You can simply do CAT7 => 305 => X520 as I do, or you can do CAT7 => 106 => X520 ... I use the dual 10g/1g SFP(+) modules on the Intel x520 (with that module, the X520 accepts 1g in)

Custom room treatments for headphone users.

Link to comment
4 hours ago, charlesphoto said:

Curious how you think it might be best to power one of these: poe or with a linear power supply (which would be an HDPLEX 100 at 12V most likely)?

 

I don’t have a POE infrastructure but it could be great.

 

I use a 12V LPS - 2A should be fine, the device sips 10W unloaded and 17W fully loaded. 

 

If not near the audio area and using fiber out, then the included SMPS should be fine.

 

I don’t think fiber is as PSU sensitive, I mean my 100Gbe NIC runs great on my SMPS powered server, and talking about hitting a tight ass eye pattern!

Custom room treatments for headphone users.

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

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.

 

Most protocols at the TCP/IP level rely on standards at the Ethernet level. In this case 802.3x aka "flow control"

 

Standards should be used whenever applicable. In this case "flow control" is not reasonably handled at the TCP/IP level rather by ASICs in network switches and endpoints. It just doesn't work well otherwise. NAA is a usermode application. It cannot effectively implement flow control.

 

Quote

 

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.

 

Wrong. pause-frames are the standard mechanism for flow control.

 

Quote

 

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.

 

This is also wrong. The Linux kernel does not send out pause-frames. pause-frames are sent out by the hardware! In your case the iMX6 MAC sends out the pause-frame, as specified by the Freescale/NXP datasheet and errata!

 

I am sorry John, you are mischaracterizing this situation. The problem is that your iMX6 processor can only internally handle 400Mbs on the 1Gbs port. Freescale/NXP says that this hardware issue should be rectified with the use of pause-frames. The hardware generates them!!!

 

It is entirely unfair to blame NAA for your own oversight. pause-frames are hardly esoteric. This is an unfair characterization. pause-frames are handled by most NICs and switches.

 

My own recommendation, here, is that audio networks should support IEEE 802.3x i.e. flow control given the presence of low powered, low bandwidth endpoints.

 

That all said @vortecjr it seems that you have enabled flow control via the FEC driver (which itself enables the iMX6 hardware pause-frames) and this is the correct behavior. This is indeed the correct fix.

 

Let me also point out that @Miska regularly contributes to the Linux kernel in the ALSA area, which he does for free, and he is largely responsible for the ALSA driver being able to handle DSD. From where I sit he is the expert here. So I felt the need to provide my independent input on this issue --- and apropos this thread, generally recommend that flow control/802.3x be enabled (there are reasons to do this beyond this issue).

 

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

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.

 

NO, pause-frames are neither esoteric, nor only applicable to NAA, pause-frames are an IEEE standard!!!

 

You should have thought about this because its in the iMX6 datasheet. Don't blame NAA. Sorry this really irritates me just own up to your mistake and issue a fix.

 

Custom room treatments for headphone users.

Link to comment

 

 

Let me clarify after a few PMs:

 

I think the combination of opticalModule and opticalRendu is terrific (or fiberoptic switch directly to opticalRendu). I am thrilled to see Sonore bring these to market. 

 

I also think the patch that Sonore is issuing is the exact correct solution (as I am imagining what it is) Just asking about the details.

 

My issues with the above posts are technical, do not reflect the Sonore products and why I am posting here, outside the Sonore subforum. 

 

These issues affect  many small low powered endpoints and perhaps many FMCs. I believe Sonore’s solution is appropriate for these as well. 

 

I do do not believe this is an issue isolated to HQPlayer/NAA and have said that. 

 

My goal here here is to promote network best practices, and for practical compatibility guidelines & solutions. Flow control is among those.

 

Feel free to have an open discussion here.

Custom room treatments for headphone users.

Link to comment
On 9/13/2019 at 5:27 PM, jabbr said:

You need an RJ-45 SFP module. I will post some compatibilities when I have time to test but they can be had for $10-20 on eBay and $40 or so on Amazon.

 

The 305 arrived and I can use the ethernet port as a fully operational port like the SFP+ ports.

Of course it is limited to 1GB. @jabbr Is that the reason you say an RJ-45 SFP module is needed? To get it up to 10GB? If yes, why is this important? If I understand well, it is not the 10GB speed that improves things for audio but the higher standards in terms of jitter that go with the 10GB protocol. Or am I wrong? 

 

audio system

 

Link to comment
50 minutes ago, bodiebill said:

 

The 305 arrived and I can use the ethernet port as a fully operational port like the SFP+ ports.

 

That’s great.

 

50 minutes ago, bodiebill said:

Of course it is limited to 1GB. @jabbr Is that the reason you say an RJ-45 SFP module is needed? To get it up to 10GB?

 

Nope. I just have some copper SFPs. It wasn’t clear that the RJ-45 ports wasn’t just for configuration — I just got this also.

 

50 minutes ago, bodiebill said:

 

If yes, why is this important? If I understand well, it is not the 10GB speed that improves things for audio but the higher standards in terms of jitter that go with the 10GB protocol. Or am I wrong? 

 

Right Jitter. Possible that the SFP ports have lower jitter (they are on a different circuit). Perhaps compare with listening test?

Custom room treatments for headphone users.

Link to comment
12 hours ago, jabbr said:

 

Most protocols at the TCP/IP level rely on standards at the Ethernet level. In this case 802.3x aka "flow control"

 

Standards should be used whenever applicable. In this case "flow control" is not reasonably handled at the TCP/IP level rather by ASICs in network switches and endpoints. It just doesn't work well otherwise. NAA is a usermode application. It cannot effectively implement flow control.

 

 

Wrong. pause-frames are the standard mechanism for flow control.

 

 

This is also wrong. The Linux kernel does not send out pause-frames. pause-frames are sent out by the hardware! In your case the iMX6 MAC sends out the pause-frame, as specified by the Freescale/NXP datasheet and errata!

 

I am sorry John, you are mischaracterizing this situation. The problem is that your iMX6 processor can only internally handle 400Mbs on the 1Gbs port. Freescale/NXP says that this hardware issue should be rectified with the use of pause-frames. The hardware generates them!!!

 

It is entirely unfair to blame NAA for your own oversight. pause-frames are hardly esoteric. This is an unfair characterization. pause-frames are handled by most NICs and switches.

 

My own recommendation, here, is that audio networks should support IEEE 802.3x i.e. flow control given the presence of low powered, low bandwidth endpoints.

 

That all said @vortecjr it seems that you have enabled flow control via the FEC driver (which itself enables the iMX6 hardware pause-frames) and this is the correct behavior. This is indeed the correct fix.

 

Let me also point out that @Miska regularly contributes to the Linux kernel in the ALSA area, which he does for free, and he is largely responsible for the ALSA driver being able to handle DSD. From where I sit he is the expert here. So I felt the need to provide my independent input on this issue --- and apropos this thread, generally recommend that flow control/802.3x be enabled (there are reasons to do this beyond this issue).

 

 

NO, pause-frames are neither esoteric, nor only applicable to NAA, pause-frames are an IEEE standard!!!

 

You should have thought about this because its in the iMX6 datasheet. Don't blame NAA. Sorry this really irritates me just own up to your mistake and issue a fix.

 

The Rendu series has always supported pause frames. Historically, customers have needed extra help with network setup if they used managed switches. The need to enable flow control in the managed switches is required to get things to work properly together. These managed switches as discussed sometimes have their flow control disabled so the request is ignored.

 

Now move forward to the introduction of the opticalModule. Two customs have reported issues with HQ Player / NAA while using an opticalModule and micro/ultraRendu combination. One customer moved to an opticalRendu which has a built-in switch which inherently doesn't have flow control issues. The other customer reports no flow control issues when he excludes the opticalModule from the network. As a result, we added some additional code to Sonic Orbiter to request pause frames when using an opticalModule and John confirmed that this worked in the lab. This fix was then uploaded to all the Rendu software and all is great. Except that this fix still doesn't work for the one customer. We don't know why the fix doesn't work for the customer but we will have an alternative for him to try soon. 

 

Jussi feels singled out here, but that is not the intent. We are simply trying to help a customer with an issue, fix anything that is needed, and move. 

 

Finally, I think you are out of line in the way you spoke to John above. You are not part of the design team, you don't know what is going on behind the scene, and you don't have all the information to accuse him of wrongdoing. 

Link to comment
31 minutes ago, vortecjr said:

Finally, I think you are out of line in the way you spoke to John above. You are not part of the design team, you don't know what is going on behind the scene, and you don't have all the information to accuse him of wrongdoing. 

 

I understand your opinion. I am not questioning your design process, rather the suggestion that Ethernet flow control is esoteric and would normally or ought be implemented in the NAA protocol. 

 

Indeed your hardware implements flow-control!

 

Again my objection was the statement starting “The issue with NAA ...” and going on to explain that pause-frames are esoteric and that “network professionals hate pause frames”.  The statement that the Linux kernel emits pause-frames is simply incorrect.

 

I don’t meant to criticize your design process but is any technical statement I’ve made wrong? Am I properly characterizing your fix as a mod to the fec driver to enable hardware pause-frames?

 

The take home message is that when dropouts occur, we all need to ensure that Ethernet flow control is enabled. Not just for Sonore products and NAA but for all products and new network audio protocols. My strong objection was that he was seeming to imply the opposite of what I just said.

Custom room treatments for headphone users.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...