Not some, all that's needed to implement AVB in a NIC, and of which, there aren't any yet except the some of the newest macbooks that are using this controller. The full Linux imp of the Jack server patches can't yet be used with a PC until the NIC cards come. Watch Marvell, too. Any time now it'll happen.
This is the most important limitation right now (today, in fact).
AVB gear (you can buy today) that I know about --
switches:
end-point dev boards:
PCIe NIC cards:
ProAudio gear:
switches:
end-point dev boards:
PCIe NIC cards:
NONE
ProAudio gear:
Last edited:
Not sure how up to date this list is. Some stuff is probably gone and newer stuff is probably not on the list.
CobraNet-Enabled Products | CobraNet HOME
But it's kind of cool to know that we have at least three viable real time audio networking technologies that enoy something more than only proprietary support: AVB, CobraNet and Dante; and that two of those are accessible to the DIY community, CobraNet and now AVB. And keep an eye out for another emerging standard from AES; X.192. It could provide the holy grail of true multi vendor interoperabilty at layer 3.
CobraNet-Enabled Products | CobraNet HOME
But it's kind of cool to know that we have at least three viable real time audio networking technologies that enoy something more than only proprietary support: AVB, CobraNet and Dante; and that two of those are accessible to the DIY community, CobraNet and now AVB. And keep an eye out for another emerging standard from AES; X.192. It could provide the holy grail of true multi vendor interoperabilty at layer 3.
That's been around since '04 or so. Of course there are loads of products. I looked at using CN in '06, but licensing cost of FPGA source was kinda high and the MAC/PHY wasn't available for app-layer TCP/UDP then either.
AVB adds what should have been in layer 2 since the onset, IMO, and without being proprietary. I'm so for this. The hell is over.
Just the damn PCIe NIC card problem with Broadcom not yet producing one using their BCM57761 controller is the only issue I see toward making a music server based on AVB. That's my intent, anyways.
Cirrus sells a chip now (since '05), no FPGA or other license needed, that works with a Davicom MAC/Phy chip. The CobraNet protocol also supports what they call 'packet bridging'. You can do TCP/UDP through the CobraNet port. I'm not advocating that this is better or worse than other options, just want to make sure the facts are understood. I don't enough about AVB to understand how an AVB client supports non AVB traffic on the same interface. I do know that the CobraNet interface gives first dibs to audio traffic bandwidth and only sends UDP, etc.. at the end of each isochronous cycle after the audio has been processed.
I like facts.. keep 'em coming 
Cirrus CS4961xx
AVB for a computer requires a NIC card that supports 802.1AS (IEEE 1588-2008, gPTP) for the high precision timestamping which is used to negotiate master clock.
The best case for AVB, to me, is that it was intended for a mixed-use network to allow A/V streams the highest priority everywhere with the addition of 802.1Qav. No dual isolated networks needed now.
Mixed Use Networks for CobraNet_CNTraining2[1]
Trouble is, all your switches need to get replaced with new ones that understand 802.1Qas.. whereas with CN you just need to keep things separate.
Cirrus CS4961xxAVB for a computer requires a NIC card that supports 802.1AS (IEEE 1588-2008, gPTP) for the high precision timestamping which is used to negotiate master clock.
The best case for AVB, to me, is that it was intended for a mixed-use network to allow A/V streams the highest priority everywhere with the addition of 802.1Qav. No dual isolated networks needed now.
Mixed Use Networks for CobraNet_CNTraining2[1]
Trouble is, all your switches need to get replaced with new ones that understand 802.1Qas.. whereas with CN you just need to keep things separate.
Wow! Where did you find that !!??
Mixed Use Networks for CobraNet_CNTraining2[1]
That't pretty ancient. I'll bet there is more relevant and succint data available somewhere. LIke here.... CobraNet Support
Mixed Use Networks for CobraNet_CNTraining2[1]
That't pretty ancient. I'll bet there is more relevant and succint data available somewhere. LIke here.... CobraNet Support
The 'latency' is a function of the protocol. I think you are actually referring to maximum allowed forwarding delay through the infrastrcuture. Add that number (3.8 mS) to the intrinsic latency of the protocol to get total latency. Keep in mind that 3.8 mS is a HUGE and pretty much never seen delay in a layer 2 subnet, which is also the layer AVB operates at. So theoretically AVB can manage this better, but in reality this is really a who cares data point. BTW, the forwarding delay limitation is not so much on the audio transport with CobraNet as it is an issue with the underlying 'beat packet' that is used to reconstruct the clock and orchestrate transmission permissions. AVB's use of IEEE 1588 for clock distribution is more robust and tolerant of forwarding delays BUT still requires consistency of delay to operate well.
I don't think that statement is true.. As with any precision time protocol, round-trip is calculated and taken into effect for proper edge.
Precision Time Protocol - Wikipedia, the free encyclopedia
Yes. But if the forwarding delsy in not consistent then it is difficult to account for. Consistency of delay will always be an issue. And that also applies to the audio frames. If a sample arrivble. Forwarding delay is one issue. Consistency of forwarding delay is another, and more important, issue, that will always apply to ANY real time media delivery system.
Typos !!!! Lets; try this again. If a sample arrives too late, then it is lost and there will be a dropout in sound. Forwarding delay is one issue. Consistency of forwarding delay is another, and more important, issue, that will always apply to ANY real time media delivery system.
BTW, I can see how 1588 would smooth out delay variations over time. I just did a little further readin on the topic here and 1588 can account for variations over time. But that still doesn't obviate the need to insure a properly provisioned net that can provide consistent delay so there are no audio dropouts (late sample arrivals).
BTW, I can see how 1588 would smooth out delay variations over time. I just did a little further readin on the topic here and 1588 can account for variations over time. But that still doesn't obviate the need to insure a properly provisioned net that can provide consistent delay so there are no audio dropouts (late sample arrivals).
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.