7 Jun
2015
7 Jun
'15
12:50 a.m.
I thought I would post this since there was a big conversation here a while
back about AES67 and the slow death of AVB due to lack of support.
Well I was talking with a guy from Meyer Sound who told me that AVB has been
resurrected from the dead. Apparently Cisco and other large network hardware
vendors were willing to back it as long as it was made more generic to
accommodate industrial uses that are also time-sensitive.
So apparently it has been re-branded as “Time-Sensitive Networking” and has a
lot more momentum behind it.
http://en.wikipedia.org/wiki/Time-Sensitive_Networking
http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_…
So make of it what you will. :) I just found it to be interesting.
-Reuben
7 Jun
7 Jun
4:16 p.m.
On Sat, 6 Jun 2015, Reuben Martin wrote:
I thought I would post this since there was a big
conversation here a while
back about AES67 and the slow death of AVB due to lack of support.
Well I was talking with a guy from Meyer Sound who told me that AVB has been
resurrected from the dead. Apparently Cisco and other large network hardware
vendors were willing to back it as long as it was made more generic to
accommodate industrial uses that are also time-sensitive.
So apparently it has been re-branded as “Time-Sensitive Networking” and has a
lot more momentum behind it.
http://en.wikipedia.org/wiki/Time-Sensitive_Networking
http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_…
Interesting.
Some notes on AoIP and Linux. There are some well funded people/companies
that use Linux for many things, but much of the development in the audio
world is with people who have hardware that they can't afford to replace
and so write drivers for. I think this is part of the reason we are not
seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena,
whatever). Right now, AoIP on Linux costs about twice as much as a normal
audio card because the Linux box requires both an interface card in the
computer as well as the Audio IF on the other end of the network cable
(not to mention a switch in the middle).
Why is this? Linux is based on lowest common denominator hardware... we
call it the PC. The Linux world has gotten much better preformance out of
this box than it was designed for. But, in the case of audio, the HW does
limit performance at least with AoIP. That limit is the clock. The PC does
not have a HW PTP clock built in and in this case software is not good
enough. The way around this is with a custom NIC that does. For some
reason even though one can buy an ethernet chip that includes a stable PTP
clock for less than $5, any NICs I have found with a PTP clock are closer
to $1k.
I was "listening in" on a IRC conversation about the differences between
ALSA and Core audio and why Core audio "does it right". The difference
ends up being this HW clock. That is ALSA is build the way it is because
the PC requires it to be.
Whats the point of all this? TSN sounds good to me. It widens the scope of
low latency networking and the requirement of distributed clocking into
areas where cost matters. I am hopeful that this means the cost of a NIC
with good HW clock will go down or even become standard. All kinds of AoIP
would see the benefit from this. I also think the cost of AoIP audio
interfaces would come down to similar cost as USB or firewire.
There is no reason we could not make an ALSA AES67 driver that would work
with any GB-NIC out there but the closed drivers now available show that
on a PC latency is double that of Core audio and handles fewer channels.
(Core audio at 192K = 64 channels in and out min latency 32 samples, Win
at 192k = 16 channels in and out min 64 samples) So any ALSA driver would
suffer from similar lower performance. This is why almost all AoIP setups
suggest their PCI(e) card in place of your stock NIC.
* numbers from:
http://www.merging.com/products/networked-audio/for-3rd-party-daw
I have seen similar numbers (or worse) elsewhere.
* I am not in any way suggesting anyone use 192k sample rate for audio
recording or streams. It's use here is only to show the difference in HW
capabilities. 48k is what I use and suggest others use.
--
Len Ovens
www.ovenwerks.net
9:08 p.m.
Just a few notes, not sure if this is of any use:
Motu and Presonus are now shipping some semi-affordable AVB audio devices
and switches. The Motu switch is $295.
All shipping Apple hardware supports AVB, via the BroadCom NIC they are
using. You could of course install Linux on said hardware.
Any computer using the same BroadCom chipset can also support AVB. For
Windows Echo Audio was making an AVB to ASIO application for this. Again
you could install Linux on any of these computers.
The NIC that the FreeScale iMX6 and Texas Instruments AM335x (of which the
BeagleBone is based) can support AVB. Some audio companies are shipping
closed AVB products based on the AM335x and iMX6 that use Linux.
I know of one developer who was thinking of making his AVB stack for Linux
on AM335x BeagleBone open source but currently it remains a closed solution.
Then of course you have the XMOS reference design but that has nothing to
do with Linux.
I think the cost to do this is becoming a non-issue, with a $200 switch and
a BeagleBone based audio interface it should be possible to make a cheap
AVB solution on Linux.
Just my 2 cents...
On Sun, Jun 7, 2015 at 7:15 AM, Len Ovens <len(a)ovenwerks.net> wrote:
On Sat, 6 Jun 2015, Reuben Martin wrote:
I thought I would post this since there was a big conversation here a
while back about AES67 and the slow death of AVB
due to lack of support.
Well I was talking with a guy from Meyer Sound who told me that AVB has
been resurrected from the dead. Apparently Cisco and other large network
hardware vendors were willing to back it as long as it was made more
generic to accommodate industrial uses that are also time-sensitive.
So apparently it has been re-branded as “Time-Sensitive Networking” and
has a lot more momentum behind it.
http://en.wikipedia.org/wiki/Time-Sensitive_Networking
http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_…
Interesting.
Some notes on AoIP and Linux. There are some well funded people/companies
that use Linux for many things, but much of the development in the audio
world is with people who have hardware that they can't afford to replace
and so write drivers for. I think this is part of the reason we are not
seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena,
whatever). Right now, AoIP on Linux costs about twice as much as a normal
audio card because the Linux box requires both an interface card in the
computer as well as the Audio IF on the other end of the network cable (not
to mention a switch in the middle).
Why is this? Linux is based on lowest common denominator hardware... we
call it the PC. The Linux world has gotten much better preformance out of
this box than it was designed for. But, in the case of audio, the HW does
limit performance at least with AoIP. That limit is the clock. The PC does
not have a HW PTP clock built in and in this case software is not good
enough. The way around this is with a custom NIC that does. For some reason
even though one can buy an ethernet chip that includes a stable PTP clock
for less than $5, any NICs I have found with a PTP clock are closer to $1k.
I was "listening in" on a IRC conversation about the differences between
ALSA and Core audio and why Core audio "does it right". The difference ends
up being this HW clock. That is ALSA is build the way it is because the PC
requires it to be.
Whats the point of all this? TSN sounds good to me. It widens the scope of
low latency networking and the requirement of distributed clocking into
areas where cost matters. I am hopeful that this means the cost of a NIC
with good HW clock will go down or even become standard. All kinds of AoIP
would see the benefit from this. I also think the cost of AoIP audio
interfaces would come down to similar cost as USB or firewire.
There is no reason we could not make an ALSA AES67 driver that would work
with any GB-NIC out there but the closed drivers now available show that on
a PC latency is double that of Core audio and handles fewer channels.
(Core audio at 192K = 64 channels in and out min latency 32 samples, Win
at 192k = 16 channels in and out min 64 samples) So any ALSA driver would
suffer from similar lower performance. This is why almost all AoIP setups
suggest their PCI(e) card in place of your stock NIC.
* numbers from:
http://www.merging.com/products/networked-audio/for-3rd-party-daw
I have seen similar numbers (or worse) elsewhere.
* I am not in any way suggesting anyone use 192k sample rate for audio
recording or streams. It's use here is only to show the difference in HW
capabilities. 48k is what I use and suggest others use.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:22 p.m.
Oh and of course you have the Open-AVB project first started by Intel.
Looks like folks are talking about getting it running on a BeagleBone or
iMX6 based board:
http://sourceforge.net/p/open-avb/mailman/message/33026258/
On Sun, Jun 7, 2015 at 12:08 PM, Jesse Cobra <jessecobra(a)gmail.com> wrote:
Just a few notes, not sure if this is of any use:
Motu and Presonus are now shipping some semi-affordable AVB audio devices
and switches. The Motu switch is $295.
All shipping Apple hardware supports AVB, via the BroadCom NIC they are
using. You could of course install Linux on said hardware.
Any computer using the same BroadCom chipset can also support AVB. For
Windows Echo Audio was making an AVB to ASIO application for this. Again
you could install Linux on any of these computers.
The NIC that the FreeScale iMX6 and Texas Instruments AM335x (of which the
BeagleBone is based) can support AVB. Some audio companies are shipping
closed AVB products based on the AM335x and iMX6 that use Linux.
I know of one developer who was thinking of making his AVB stack for Linux
on AM335x BeagleBone open source but currently it remains a closed solution.
Then of course you have the XMOS reference design but that has nothing to
do with Linux.
I think the cost to do this is becoming a non-issue, with a $200 switch
and a BeagleBone based audio interface it should be possible to make a
cheap AVB solution on Linux.
Just my 2 cents...
On Sun, Jun 7, 2015 at 7:15 AM, Len Ovens <len(a)ovenwerks.net> wrote:
On Sat, 6 Jun 2015, Reuben Martin wrote:
I thought I would post this since there was a big conversation here a
while back about AES67 and the slow death of AVB
due to lack of support.
Well I was talking with a guy from Meyer Sound who told me that AVB has
been resurrected from the dead. Apparently Cisco and other large network
hardware vendors were willing to back it as long as it was made more
generic to accommodate industrial uses that are also time-sensitive.
So apparently it has been re-branded as “Time-Sensitive Networking” and
has a lot more momentum behind it.
http://en.wikipedia.org/wiki/Time-Sensitive_Networking
http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_…
Interesting.
Some notes on AoIP and Linux. There are some well funded people/companies
that use Linux for many things, but much of the development in the audio
world is with people who have hardware that they can't afford to replace
and so write drivers for. I think this is part of the reason we are not
seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena,
whatever). Right now, AoIP on Linux costs about twice as much as a normal
audio card because the Linux box requires both an interface card in the
computer as well as the Audio IF on the other end of the network cable (not
to mention a switch in the middle).
Why is this? Linux is based on lowest common denominator hardware... we
call it the PC. The Linux world has gotten much better preformance out of
this box than it was designed for. But, in the case of audio, the HW does
limit performance at least with AoIP. That limit is the clock. The PC does
not have a HW PTP clock built in and in this case software is not good
enough. The way around this is with a custom NIC that does. For some reason
even though one can buy an ethernet chip that includes a stable PTP clock
for less than $5, any NICs I have found with a PTP clock are closer to $1k.
I was "listening in" on a IRC conversation about the differences between
ALSA and Core audio and why Core audio "does it right". The difference ends
up being this HW clock. That is ALSA is build the way it is because the PC
requires it to be.
Whats the point of all this? TSN sounds good to me. It widens the scope
of low latency networking and the requirement of distributed clocking into
areas where cost matters. I am hopeful that this means the cost of a NIC
with good HW clock will go down or even become standard. All kinds of AoIP
would see the benefit from this. I also think the cost of AoIP audio
interfaces would come down to similar cost as USB or firewire.
There is no reason we could not make an ALSA AES67 driver that would work
with any GB-NIC out there but the closed drivers now available show that on
a PC latency is double that of Core audio and handles fewer channels.
(Core audio at 192K = 64 channels in and out min latency 32 samples, Win
at 192k = 16 channels in and out min 64 samples) So any ALSA driver would
suffer from similar lower performance. This is why almost all AoIP setups
suggest their PCI(e) card in place of your stock NIC.
* numbers from:
http://www.merging.com/products/networked-audio/for-3rd-party-daw
I have seen similar numbers (or worse) elsewhere.
* I am not in any way suggesting anyone use 192k sample rate for audio
recording or streams. It's use here is only to show the difference in HW
capabilities. 48k is what I use and suggest others use.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
13 Jun
13 Jun
8:31 p.m.
On Sun, 7 Jun 2015, Jesse Cobra wrote:
Just a few notes, not sure if this is of any use:
Motu and Presonus are now shipping some semi-affordable AVB audio devices and
switches. The Motu switch is $295.
Here is an even cheaper switch:
http://www.dsp4you.com/products/avb-oem-series/avb-sw
It is not Gb, just 100M, but less than half the price and possibly "good
enough" for testing, development, smaller channel counts (32ish?)
It appears that at the same time as being a switch it could also be set up
as an endpoint. There is I2S connections on it. So it could be a good
starter set up with switch and 8audio i/o. I think, the spec just says:
"Internal 20pin 0.1” pitch connector with TDM/I2S input & output streaming
AVBTP (IEEE 1722) talker listener mode
Up to 8ch per stream
Sample rate of 44.1/48/88.2/96/176.4/192kHz
Sample width of 20/24bit
Automatic hardware locking to stream’s media using the IEEE 1722
presentation time"
And last of all, This looks like a ready to run AVB interface that will
work on Linux:
http://www.dsp4you.com/downloads/AV2USB%20Datasheet.pdf
I could not find the price though. It is limited to 8/8 i/o and looks to
Linux as a class compliant USB 2.0 8channel audio card. Of course those 8
channels can be any of the available AVB channels on the AVB network. More
than one of these could be used on the same computer for 16 channels (or
more) as they are by default synced. I would suggest a variant of zita-a2j
with no resample to connect 2nd and more units rather than making a
"multi-device". This would allow plugging and un-plugging without stopping
jackd. Also, if your "internal" AI has external sync capability (s/pdif or
word clock) it could be used by the jack back end and av2usb boxes added
as clients if at least one of the AVB audio IF boxes had a similar sync
out.
This may also be an inexpensive way of using network for audio transport
from one computer to another in the same LAN with low latency. Two
ethernet ports means a switch may not be needed. (aside from audio
streaming a net port would be needed to control routing too unless that is
somehow incorperated in the USB line)
--
Len Ovens
www.ovenwerks.net
8:44 p.m.
On Sat, 13 Jun 2015 11:31:07 -0700 (PDT)
Len Ovens <len(a)ovenwerks.net> wrote:
On Sun, 7 Jun 2015, Jesse Cobra wrote:
Better and better :D
I don't suppose anyone has written an AVB -> jack module?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Just a few notes, not sure if this is of any
use:
Motu and Presonus are now shipping some semi-affordable AVB audio devices and
switches. The Motu switch is $295.
Here is an even cheaper switch:
http://www.dsp4you.com/products/avb-oem-series/avb-sw
It is not Gb, just 100M, but less than half the price and possibly "good
enough" for testing, development, smaller channel counts (32ish?)
It appears that at the same time as being a switch it could also be set up
as an endpoint. There is I2S connections on it. So it could be a good
starter set up with switch and 8audio i/o. I think, the spec just says:
"Internal 20pin 0.1” pitch connector with TDM/I2S input & output streaming
AVBTP (IEEE 1722) talker listener mode
Up to 8ch per stream
Sample rate of 44.1/48/88.2/96/176.4/192kHz
Sample width of 20/24bit
Automatic hardware locking to stream’s media using the IEEE 1722
presentation time"
And last of all, This looks like a ready to run AVB interface that will
work on Linux:
http://www.dsp4you.com/downloads/AV2USB%20Datasheet.pdf
I could not find the price though. It is limited to 8/8 i/o and looks to
Linux as a class compliant USB 2.0 8channel audio card. Of course those 8
channels can be any of the available AVB channels on the AVB network. More
than one of these could be used on the same computer for 16 channels (or
more) as they are by default synced. I would suggest a variant of zita-a2j
with no resample to connect 2nd and more units rather than making a
"multi-device". This would allow plugging and un-plugging without stopping
jackd. Also, if your "internal" AI has external sync capability (s/pdif or
word clock) it could be used by the jack back end and av2usb boxes added
as clients if at least one of the AVB audio IF boxes had a similar sync
out.
This may also be an inexpensive way of using network for audio transport
from one computer to another in the same LAN with low latency. Two
ethernet ports means a switch may not be needed. (aside from audio
streaming a net port would be needed to control routing too unless that is
somehow incorperated in the USB line)
--
Len Ovens
www.ovenwerks.net
10:14 p.m.
On Sat, 13 Jun 2015, Will Godfrey wrote:
I don't suppose anyone has written an AVB ->
jack module?
https://github.com/audioscience/Open-AVB
Does in fact list both a jackd listener and talker in their examples. The
talker looks like it is more complete and would be able to run waiting for
a listener to be connected. The listener expects the talker to be ready to
send and will die if the talker is not there... so it would be best
started by a connection application that knows what is there.
In the end, the Linux community would probably be more thankful for an
ALSA module. I think a Jack client would be easier to write though and
actually makese more sense in an ecosystem where connections come and go
and connections can go anywhere.
Just found:
https://github.com/audioscience/avdecc-lib
Which is a lib for IEEE1722.1 (AVB Device Enumeration, Discovery and
Control) that comes with a commandline controller. This allows Linux to
discover and control AVB end points... That is make connections. At least
a GUI cross point style control application would be very nice. But at
least the CLI utility would allow things to be usable.
An application like Qjackctl, Patchage or Ardour's Audio Connection
Manager that covered both internal jackd connections as well as external
AVB connections where an AVB jack client is started at connection time
would be nice. It looks like it would be possible with just the libs and
utilities listed here already.
I'll see how far I get when I have some HW to play with. I am sure I have
made it sound too easy by far.
--
Len Ovens
www.ovenwerks.net
11:51 p.m.
Here is an even cheaper switch:
http://www.dsp4you.com/products/avb-oem-series/avb-sw
I think I have one of these around here as well from an old project. I will
send it along with the xmos endpoints!
I should have a few Marvell firefox and apx 2 AVB eval kits kicking around
I will look for...
Also, the AVB community is starting to call it TSN (time sensitive
networks)... ;)
On Sat, Jun 13, 2015 at 1:14 PM, Len Ovens <len(a)ovenwerks.net> wrote:
On Sat, 13 Jun 2015, Will Godfrey wrote:
I don't suppose anyone has written an AVB -> jack module?
https://github.com/audioscience/Open-AVB
Does in fact list both a jackd listener and talker in their examples. The
talker looks like it is more complete and would be able to run waiting for
a listener to be connected. The listener expects the talker to be ready to
send and will die if the talker is not there... so it would be best started
by a connection application that knows what is there.
In the end, the Linux community would probably be more thankful for an
ALSA module. I think a Jack client would be easier to write though and
actually makese more sense in an ecosystem where connections come and go
and connections can go anywhere.
Just found:
https://github.com/audioscience/avdecc-lib
Which is a lib for IEEE1722.1 (AVB Device Enumeration, Discovery and
Control) that comes with a commandline controller. This allows Linux to
discover and control AVB end points... That is make connections. At least a
GUI cross point style control application would be very nice. But at least
the CLI utility would allow things to be usable.
An application like Qjackctl, Patchage or Ardour's Audio Connection
Manager that covered both internal jackd connections as well as external
AVB connections where an AVB jack client is started at connection time
would be nice. It looks like it would be possible with just the libs and
utilities listed here already.
I'll see how far I get when I have some HW to play with. I am sure I have
made it sound too easy by far.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
14 Jun
14 Jun
12:18 a.m.
On Sat, 13 Jun 2015, Jesse Cobra wrote:
Also, the AVB community is starting to call it TSN
(time sensitive networks)...
;)
As happens, searching for TSN gives many hits for a Sports network... I
was looking for what the T was for, but it apparently is just "The". AVB
is much more searchable, I hope it sticks around as TSN(AVB) or something.
I feel about as safe with a network controlled automotive braking system
as an MS inspired automotive engine control computer.
--
Len Ovens
www.ovenwerks.net
8 Jun
8 Jun
2:48 p.m.
On Sun, Jun 7, 2015 at 10:15 AM, Len Ovens <len(a)ovenwerks.net> wrote:
I was "listening in" on a IRC conversation
about the differences between
ALSA and Core audio and why Core audio "does it right". The difference ends
up being this HW clock. That is ALSA is build the way it is because the PC
requires it to be.
This isn't true.
I'm not sure what you're thinking of/referring to.
9 Jun
9 Jun
4:14 a.m.
On 06/07/2015 07:15 AM, Len Ovens wrote:
...
Why is this? Linux is based on lowest common
denominator hardware... we
call it the PC. The Linux world has gotten much better preformance out
of this box than it was designed for. But, in the case of audio, the HW
does limit performance at least with AoIP. That limit is the clock. The
PC does not have a HW PTP clock built in and in this case software is
not good enough. The way around this is with a custom NIC that does. For
some reason even though one can buy an ethernet chip that includes a
stable PTP clock for less than $5, any NICs I have found with a PTP
clock are closer to $1k.
An Intel I210 Gigabit Ethernet PCI express Card will set you back about
$70 on Newegg, it does have the hardware support that AVB needs and a
driver in the OpenAVB project. I have a couple and they seem to work
just fine. A 24 output AVB Motu box is $995.
I'm actually trying to get this going with one of these AO24 Motu
"soundcards" (starting with OpenAVB). I have gotten as far as the
OpenAVB stack talking to the Motu card and slaving its clock to it (and
the Motu box recognizing it is now the master clock source and AVB is
active). Audio streaming is next, I'm just not finding the free time to
do this (anyone gotten further along on this??).
First goal would be a simple jack client that can stream samples, end
game would be a jack backend so this can be treated as a soundcard.
We'll see...
-- Fernando
5:08 a.m.
Sounds awesome Fernando.
I have a few of the XMOS AVB endpoints I am not using if anyone wants one.
On Mon, Jun 8, 2015 at 7:14 PM, Fernando Lopez-Lezcano <
nando(a)ccrma.stanford.edu> wrote:
On 06/07/2015 07:15 AM, Len Ovens wrote:
...
Why is this? Linux is based on lowest common
denominator hardware... we
call it the PC. The Linux world has gotten much better preformance out
of this box than it was designed for. But, in the case of audio, the HW
does limit performance at least with AoIP. That limit is the clock. The
PC does not have a HW PTP clock built in and in this case software is
not good enough. The way around this is with a custom NIC that does. For
some reason even though one can buy an ethernet chip that includes a
stable PTP clock for less than $5, any NICs I have found with a PTP
clock are closer to $1k.
An Intel I210 Gigabit Ethernet PCI express Card will set you back about
$70 on Newegg, it does have the hardware support that AVB needs and a
driver in the OpenAVB project. I have a couple and they seem to work just
fine. A 24 output AVB Motu box is $995.
I'm actually trying to get this going with one of these AO24 Motu
"soundcards" (starting with OpenAVB). I have gotten as far as the OpenAVB
stack talking to the Motu card and slaving its clock to it (and the Motu
box recognizing it is now the master clock source and AVB is active). Audio
streaming is next, I'm just not finding the free time to do this (anyone
gotten further along on this??).
First goal would be a simple jack client that can stream samples, end game
would be a jack backend so this can be treated as a soundcard. We'll see...
-- Fernando
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:10 p.m.
On Mon, 8 Jun 2015, Fernando Lopez-Lezcano wrote:
An Intel I210 Gigabit Ethernet PCI express Card will
set you back about $70
on Newegg, it does have the hardware support that AVB needs and a driver in
the OpenAVB project. I have a couple and they seem to work just fine. A 24
output AVB Motu box is $995.
The Intel I210 Gigabit Ethernet PCI express Card has gone up they are $90
now, but still reasonable. ( this one?
http://www.newegg.ca/Product/Product.aspx?Item=N82E16833106176 )
This one says it has the same chip for only $50:
http://www.newegg.ca/Product/Product.aspx?Item=N82E16833316879
This one (at $30) I might stay away from:
http://www.canadacomputers.com/product_info.php?cPath=27_1048_1052&item…
It says it is an "Intel I210T1 Comp." The comp. meaning compatible. It
actually has the intel 82574 in it not the I210T1. The Intel documentation
does not mention AVB support as it does for the above cards.
The intel card at the top looks like it has a coax connector on the board.
The intel site does not make any mention of it though. The I210 chip does
have 4 GPi/o, I wonder if it is connected to one of these (can be made to
provide word clock or a multiple). Though I would guess it defaults to
PPS?
I'm actually trying to get this going with one of
these AO24 Motu
The MOTU UltraLite AVB looks more interesting to me. 10/10 i/o with midi.
A bit cheaper ($700), can still get an extra 8 i/o with adat. But yes the
price is getting managable.
"soundcards" (starting with OpenAVB). I have
gotten as far as the OpenAVB
stack talking to the Motu card and slaving its clock to it (and the Motu box
recognizing it is now the master clock source and AVB is active). Audio
streaming is next, I'm just not finding the free time to do this (anyone
gotten further along on this??).
For me, even $700 is not cheap. The ethernet card or two is a possibility.
For as far as you have gotten, what is the cpu load like? Does it affect
the DSP load as jack shows it while jack is connected to the internal card
at low latency?
First goal would be a simple jack client that can
stream samples, end game
would be a jack backend so this can be treated as a soundcard. We'll see...
The jack client should work with a PCI(e) card that has word clock in or
spdif in. In my case I could use the spdif out to sync my internal card.
This would sync jack to the MOTU (or other AVB device).
This is (so far) sounding cheaper than any other AoIP aside from netjack.
Netjack is fine for connecting two computers but not so much for adding
inputs. It is also sounding more like there is some movement with it in
the linux world. In any case an ethernet card is the first step.
--
Len Ovens
www.ovenwerks.net
5:37 p.m.
Few comments inline.
Eric Mann / OpenAVB contributor ...
-----Original Message-----
From: Linux-audio-dev [mailto:linux-audio-dev-bounces@lists.linuxaudio.org] On Behalf Of
Len Ovens
Sent: Tuesday, June 09, 2015 6:08 AM
To: Fernando Lopez-Lezcano
Cc: LAD
Subject: Re: [LAD] AVB not so dead after all
On Mon, 8 Jun 2015, Fernando Lopez-Lezcano wrote:
An Intel I210 Gigabit Ethernet PCI express Card will
set you back
about $70 on Newegg, it does have the hardware support that AVB needs
and a driver in the OpenAVB project. I have a couple and they seem to
work just fine. A 24 output AVB Motu box is $995.
The Intel I210 Gigabit Ethernet PCI express Card has gone up they are $90 now, but still
reasonable.
Ekm> IMO you should be able to get a card for <$70 - and I've seen them one in a
while on amazon for much less (we sell 5-packs which resellers can unbundle and sell
individually for a discount).
http://ark.intel.com/products/68668/Intel-Ethernet-Server-Adapter-I210-T1 .
This one (at $30) I might stay away from:
http://www.canadacomputers.com/product_info.php?cPath=27_1048_1052&item…
It says it is an "Intel I210T1 Comp." The comp. meaning compatible. It actually
has the intel 82574 in it not the I210T1. The Intel documentation does not mention AVB
support as it does for the above cards.
Ekm> The 82574 does not support the AVB features - the I210 replaced functionally the
82574 ...
The intel card at the top looks like it has a coax connector on the board.
Ekm> no coax on any I210 cards I am aware of. The I210 itself comes in three versions -
a 'standard' (AT) version with an integrated 1GBASE-T PHY (aka an RJ-45), an
'industrial temp' (IT) 1GBASE-T version which is rated for -40 to +70 C, and an
SGMII version (which is only interesting if you are building your own boards ...). There
is also the I211, which is basically the same design except the AVB features (and other
things) have been fused off (disabled) in manufacturing. The I211 adapters are usually
lower price, as it doesn't need external FLASH for configuration among other things.
The intel site does not make any mention of it though. The I210 chip does have 4 GPi/o, I
wonder if it is connected to one of these (can be made to provide word clock or a
multiple). Though I would guess it defaults to PPS?
Ekm> If you buy the Intel manufactured I210-AT card, there is a header on the board -
the top two pairs of pins are connected to 'timed' GPIOs (GND/SDP1 and GND/SDP2)
on the I210 - either pin can either be configured as an input or an output. Some use it to
sample edges and converts to the internal 'gPTP' time, while others drive out a
clock on some period - either PPS or whatever frequency you want.
First goal would be a simple jack client that can
stream samples, end game
would be a jack backend so this can be treated as a soundcard. We'll see...
Ekm> There is a gstreamer plug-in on the OpenAVB website - which either sends or
receives AVB streams already. The receiver AFAIK records the stream to a file. I thought
there was a jack plug-in or sorts as well ... but ... maybe it was only in staging and not
the main branch ...
Hths.
Eric Mann / Intel Networking Division
16 Jun
16 Jun
1:06 a.m.
Looking at the MOTU AVB endpoints, I see MIDI ports on them. None of the
AVB docs I have read (yet) show MIDI transport. Is this then just RTP-MIDI
on the same network? It almost seems that the midi is visible to the USB
part only.
Motu recommends connecting one of the AVB boxes to the computer via USB or
Thunderbolt and streaming all avb channels through that connection. So
this would mean that the BOX closest to the computer is the audio
interface. With Thunderbolt the maximum channel count is 128 with any mix
of i/o from that (example 64/64 i/o).
Connection to the computer via AVB:
http://www.motu.com/avb/using-your-motu-avb-device-as-a-mac-audio-interface…
shows some limitations:
- SR can be 48k and multiples but not 44.1k and multiples
- The Mac will insist on being the master clock
- The Mac locks each enabled AVB device for exclusive access.
(The mac can talk to more than one AVB device but they can't
talk to each over or be connected to each other while the Mac
has control)
- Maximum channels is still 128 at least on a late 2013 Mac Pro. earlier
models should not expect more than 32 total channels (mix of i/o)
- Motu AVB devices set all streams to 8 channels, no 2 ch streams allowed.
- Because the AVB network driver on Mac looks like a sound card, Audio SW
needs to be stopped before changing channel counts. (adding or
removing IF boxes)
I think that a Linux driver has the potential to do better in at least
some cases. I personally would be quite happy with 48k SR only, but I am
sure someone will make it better. Linux does not have to be the Master
Clock unless it must sync to an internal card that only has some kind of
sync out but can't lock to anything (like some of the on board AIs that
have a s/pdif out). In the Linux case, the AVB AI may well be the only
used AI and the internal AI can't be synced to anyway. With Jack, channels
can come and go with no ill effect except a connection vanishes. Channels
can be added and removed even within a jack client. This _should_
(logically) be possible in a Jack backend, but maybe not wise. A sync only
backend may be better that takes it's media clock from the AVB clock as
this would add stability in case of an avb box being disconnected. I do
not know if jack backends can deal with 0 or more channels with their
number changing, but a client dying because it's remote AI vanished would
not crash jack. The problem with using clients for the AI is that
auto-connecting APPs look for system/playback_1 and _2. Even more jack
aware apps like Ardour would have you looking in "other" for more inputs.
Anyway, getting AVB working with Linux is first (even two channels).
--
Len Ovens
www.ovenwerks.net
21 Jul
21 Jul
9:31 p.m.
Related to this topic, I would recommend reading through this...
https://groups.google.com/forum/#!topic/theatre-sound-list/WbysqMHs6iw
AVB isn't dead no, but it certainly isn't close to dominant at this point,
at least on my side of the pond. It may be a different situation on the
other side, no idea. That being said, it has a very uphill battle to
displace Dante at this point on my side of the pond and get decent usage
professionally.
Then again if AES67 interoperability comes into play, then is may be a moot
point as ideally you would be able to communicate between the two protocols.
Seablade
On Mon, Jun 15, 2015 at 7:05 PM, Len Ovens <len(a)ovenwerks.net> wrote:
Looking at the MOTU AVB endpoints, I see MIDI ports on them. None of the
AVB docs I have read (yet) show MIDI transport. Is this then just RTP-MIDI
on the same network? It almost seems that the midi is visible to the USB
part only.
Motu recommends connecting one of the AVB boxes to the computer via USB or
Thunderbolt and streaming all avb channels through that connection. So this
would mean that the BOX closest to the computer is the audio interface.
With Thunderbolt the maximum channel count is 128 with any mix of i/o from
that (example 64/64 i/o).
Connection to the computer via AVB:
http://www.motu.com/avb/using-your-motu-avb-device-as-a-mac-audio-interface…
shows some limitations:
- SR can be 48k and multiples but not 44.1k and multiples
- The Mac will insist on being the master clock
- The Mac locks each enabled AVB device for exclusive access.
(The mac can talk to more than one AVB device but they can't
talk to each over or be connected to each other while the Mac
has control)
- Maximum channels is still 128 at least on a late 2013 Mac Pro. earlier
models should not expect more than 32 total channels (mix of i/o)
- Motu AVB devices set all streams to 8 channels, no 2 ch streams allowed.
- Because the AVB network driver on Mac looks like a sound card, Audio SW
needs to be stopped before changing channel counts. (adding or
removing IF boxes)
I think that a Linux driver has the potential to do better in at least
some cases. I personally would be quite happy with 48k SR only, but I am
sure someone will make it better. Linux does not have to be the Master
Clock unless it must sync to an internal card that only has some kind of
sync out but can't lock to anything (like some of the on board AIs that
have a s/pdif out). In the Linux case, the AVB AI may well be the only used
AI and the internal AI can't be synced to anyway. With Jack, channels can
come and go with no ill effect except a connection vanishes. Channels can
be added and removed even within a jack client. This _should_ (logically)
be possible in a Jack backend, but maybe not wise. A sync only backend may
be better that takes it's media clock from the AVB clock as this would add
stability in case of an avb box being disconnected. I do not know if jack
backends can deal with 0 or more channels with their number changing, but a
client dying because it's remote AI vanished would not crash jack. The
problem with using clients for the AI is that auto-connecting APPs look for
system/playback_1 and _2. Even more jack aware apps like Ardour would have
you looking in "other" for more inputs.
Anyway, getting AVB working with Linux is first (even two channels).
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
23 Jul
23 Jul
6:36 a.m.
On Tue, 21 Jul 2015, Thomas Vecchione wrote:
Related to this topic, I would recommend reading
through this...
https://groups.google.com/forum/#!topic/theatre-sound-list/WbysqMHs6iw
AVB isn't dead no, but it certainly isn't close to dominant at this point, at
least on my side of the pond. It may be a different situation on the other side,
no idea. That being said, it has a very uphill battle to displace Dante at this
point on my side of the pond and get decent usage professionally.
You are exactly right. However, for most of us, it is a matter of what can
work with Linux and has open drivers. Right now nothing. The chances of
some Dante box having a linux OS in it is probably quite high, but I can't
even buy a closed version at this point (though I hear there are some
around). And the HW to go with such a driver is not cheap (at least not
cheap enough for me to buy when it may never work).
Then again if AES67 interoperability comes into play,
then is may be a moot point
as ideally you would be able to communicate between the two protocols.
AES67 right now is the same. There are no Linux drivers and none in the
works so far as I know. There are some audio cards that are basically
AES67 ends, but again they are not cheap.
AVB is far from dominant for sure, but there is an open driver (well sort
of... a group of bits that can be put together to make things work is more
like it) in the works. It does require some special HW, but the gist of
the thread is that the cost of that HW has come within reach. In other
words, the average experimenter with no backing can start to tinker.
There is an option to still make use of AVB equipment if one can't make
this work, not cheap ($600) but similar to a USB AI with the same feature
set that will act as either a USB (USB2.0 compliant it says) AI with AVB
bridging or as an AVB AI. SO not a loss if things don't go well or not
unusable while working on things. The internals can be controled via a web
browser on the avb port even with no AVB stuff attached.
Along with this, parts of the linux AVB driver and HW needed (the NIC for
example) will be usable for AES67 development if someone chooses to do
that.
So AVB development may not seem like the best way to go, but right now it
is the only way that at least seems open and in the end seems to also have
the edge quality wise (perhaps that is debatable... I won't bother arguing
either way).
So for me, it is about accessability. I am a hobbiest (at this point
anyway) and Dante/AES67/Ravenna are out of my reach. AVB seems to have
entered into that accessable place.
One thing I will say is that Dante and AVB can coexist on the same
network, it should not be very hard to make a box with only one NIC that
can bridge the two... and make whatever in on one protocol look like it is
on the other.
--
Len Ovens
www.ovenwerks.net
3198
days inactive
3245
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
Fernando Lopez-Lezcano -
Jesse Cobra -
Len Ovens -
Mann, Eric -
Paul Davis -
Reuben Martin -
Thomas Vecchione -
Will Godfrey