Nice thing about AES67 is that you can also, in theory, run the preamps and ADCs off PoE.
AES67 resources – Audio over IP protocol
11–20 of 35 posts
Re: AES67 resources – Audio over IP protocol
#12This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…
While this can't be dropped into a lot of existing networks, that doesn't really eliminate the advantages of IP. This might be best explained by analogy: VoIP. Various issues including security model, DHCP-based provisioning, and QoS mean that corporate VoIP phones are typically deployed on a specially prepared network using a dedicated VLAN. While various VoIP vendors claim that you can just drop their solution on y…
But is a latency of 2ms up to 50ms really attractive? I am in no way near audio engineering, but i can remember the MIDI-folks swearing about their 2ms latency.
Re: AES67 resources – Audio over IP protocol
#13This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…
No, because automotive is the use case driving this and consumer/professional audio will come along for the ride. Think about how you synchronize the LCDs and speakers in an SUV--Ethernet is way easier than just about any other solution.
The biggest obstacle to adoption in the consumer/prosumer space is the fact that everybody killed Ethernet ports on their laptops.
Re: AES67 resources – Audio over IP protocol
#14Remembered this a few days ago when watching the recent Wintergatan video where buddy there hooks up this massive multicore with a bunch of preamps to the Marble Machine X, and I'm just there thinking “It sure is satisfying to attach and click in a 28-channel multicore cable, but why not use AES67 (or AES50 for that matter)?”. Nice thing about AES67 is that you can also, in theory, run the preamps and ADCs off PoE.
Re: AES67 resources – Audio over IP protocol
#15This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…
I had a look at 1588 and was a rabbit hole of paywalls - latest draft seems to be https://standards.ieee.org/standard/1588-2019.html Why is a standards group paywalled!
This is their business model. You pay for access to the standards documents, and that money funds the development and maintenance process. It's supported by governments requiring adherence to these standards, so implementors are obliged to purchase them.
Gratis access to standards is a newer model which relies on a different funding stream. The IETF is one such example.
Re: AES67 resources – Audio over IP protocol
#16Earlier quoted context omitted.
While this can't be dropped into a lot of existing networks, that doesn't really eliminate the advantages of IP. This might be best explained by analogy: VoIP. Various issues including security model, DHCP-based provisioning, and QoS mean that corporate VoIP phones are typically deployed on a specially prepared network using a dedicated VLAN. While various VoIP vendors claim that you can just drop their solution on y…
I get your point, and you may be right and it might take off. But is a latency of 2ms up to 50ms really attractive? I am in no way near audio engineering, but i can remember the MIDI-folks swearing about their 2ms latency.
Re: AES67 resources – Audio over IP protocol
#17This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…
> But isn't this dead before it really lifts off? No, because automotive is the use case driving this and consumer/professional audio will come along for the ride. Think about how you synchronize the LCDs and speakers in an SUV--Ethernet is way easier than just about any other solution. The biggest obstacle to adoption in the consumer/prosumer space is the fact that everybody killed Ethernet ports on their laptops.
This isn't how you connect something trivial like an LCD to your speakers, it's how you rig up the audio system at a theme park or network the audio feeds for all the broadcasters at a World Cup match. Those are two applications that AES67 committee members had worked on and where it will probably be deployed.
Re: AES67 resources – Audio over IP protocol
#18This sounds like fun tech. But isn't this dead before it really lifts off? Intel 1588 is not supported by every customer-NIC, and far from supported by most switches and such. So if i have to build a "special" hardware environment anyway, why use AES67 and not some other proprietary solution without IP which may (? or may not) deliver better latency and jitter? Last time i checked (which is a while back), the same su…
Not for consumer products, but it's not optimized for those. If you buy any kind of professional NICs and switches, 1588 support isn't that hard to find. Wide support means less trouble if one manufacturer changes things, more choice in hardware than a proprietary system would likely have. Can live with existing networks.
E.g. lets say you're building out an event at a large convention center. They probably can give you Ethernet or fiber from one end of the building to the other, but can they give it to you for your proprietary thing of choice?
Or you are making a permanent installation: do you want to have to put one vendors stuff everywhere, as a parallel network of proprietary stuff, or do you prefer something that works on the network infrastructure you already have, with maybe some upgrades to some components, but keeping it with the stuff your network people already know? Especially if it means you don't need to pull additional cabling or fiber everywhere?
Re: AES67 resources – Audio over IP protocol
#19Earlier quoted context omitted.
I get your point, and you may be right and it might take off. But is a latency of 2ms up to 50ms really attractive? I am in no way near audio engineering, but i can remember the MIDI-folks swearing about their 2ms latency.
Not very good keyboard player here: higher than ~~8ms is annoying for playing/recording. But 50ms probably isn't bad if say, you're blasting a message through a factory intercom, or piping music through a dental office, or stuff like that.
Re: AES67 resources – Audio over IP protocol
#20Earlier quoted context omitted.
> But isn't this dead before it really lifts off? No, because automotive is the use case driving this and consumer/professional audio will come along for the ride. Think about how you synchronize the LCDs and speakers in an SUV--Ethernet is way easier than just about any other solution. The biggest obstacle to adoption in the consumer/prosumer space is the fact that everybody killed Ethernet ports on their laptops.
What? I've been going to AES67 meetings and talks for several years and worked on AoIP products, I don't think I've ever met someone from the automotive industry or heard they used the protocols that AES67 is going to supplant/integrate with (Dante, Ravenna, etc). The standards committees members were professional and commercial audio manufacturers. This isn't how you connect something trivial like an LCD to your spe…