Discussion:
[Jack-Devel] AES67 / SMPTE ST 2110-30
Philippe Bekaert
2017-09-27 14:20:27 UTC
Permalink
Anyone working on AES67 / ST 2110-30 interfacing with jack audio?
I’m considering to take up the glove, if it doesn’t already exist.
Could also be a nice replacement for the net drivers.
Best,

Philippe.

Philippe Bekaert
full professor - project leader
Expertise center for Digital Media - Hasselt University
Wetenschapspark 2 - 3590 Diepenbeek - Belgium
Tel: +32 11 268411
www.edm.uhasselt.be
Spencer Russell
2017-09-27 17:37:48 UTC
Permalink
That would be an amazing contribution. I'm seeing more AES67 gear show
up in the studios I frequent and being able to route to/from those
devices using JACK would be great.

-s
Post by Philippe Bekaert
Anyone working on AES67 / ST 2110-30 interfacing with jack audio?
I’m considering to take up the glove, if it doesn’t already exist.
Could also be a nice replacement for the net drivers.
Best,
Philippe.
Philippe Bekaert
full professor - project leader
Expertise center for Digital Media - Hasselt University
Wetenschapspark 2 - 3590 Diepenbeek - Belgium
Tel: +32 11 268411
www.edm.uhasselt.be
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
happy musicmaker
2017-09-28 03:26:41 UTC
Permalink
That is such good news. What(low cost) hardware would this development be
used on to support the developers with testing/debugging and maybe even
development ?

* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)

I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.

My two wishes:
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.

With those two, the Linux Audio environment would be perfect and the world
a better place.

On Thu, Sep 28, 2017 at 11:20 AM, happy musicmaker <
That is such good news. What(low cost) hardware would this development
be used on to support the developers with testing/debugging and maybe even
development ?
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and the
world a better place.
Post by Spencer Russell
That would be an amazing contribution. I'm seeing more AES67 gear show
up in the studios I frequent and being able to route to/from those
devices using JACK would be great.
-s
Post by Philippe Bekaert
Anyone working on AES67 / ST 2110-30 interfacing with jack audio?
I’m considering to take up the glove, if it doesn’t already exist.
Could also be a nice replacement for the net drivers.
Best,
Philippe.
Philippe Bekaert
full professor - project leader
Expertise center for Digital Media - Hasselt University
Wetenschapspark 2 - 3590 Diepenbeek - Belgium
Tel: +32 11 268411 <+32%2011%2026%2084%2011>
www.edm.uhasselt.be
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
happy musicmaker
2017-09-28 03:31:11 UTC
Permalink
That is such good news. What(low cost) hardware would this development be
used on to support the developers with testing/debugging and maybe even
development ?

* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)

I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.

My two wishes:
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.

With those two, the Linux Audio environment would be perfect and the world
a better place.

*(Apology for the re-sends and ignore the previous edits. Web based Gmail
is such a annoyance and un-logically structured)*
happy musicmaker
2017-09-28 06:33:43 UTC
Permalink
MOTU just released the 828es with AVB and USB standard compliant and two
ADAT I/O and Web based (not ALSA) mixer. That would be, for now, the
ultimate (AVB) interface for Linux, if it works.

On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker <
Post by happy musicmaker
That is such good news. What(low cost) hardware would this development
be used on to support the developers with testing/debugging and maybe even
development ?
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and the
world a better place.
*(Apology for the re-sends and ignore the previous edits. Web based Gmail
is such a annoyance and un-logically structured)*
Christoph Kuhr
2017-09-28 10:11:59 UTC
Permalink
With an Intel I210 NIC you can already have AVB in combination with
Jack. But you have to do some coding yourself to fit your purposes..


BTW:
I would never recommend buying MOTU.


BR,
Ck
Post by happy musicmaker
MOTU just released the 828es with AVB and USB standard compliant and two
ADAT I/O and Web based (not ALSA) mixer. That would be, for now, the
ultimate (AVB)  interface for Linux,  if it works.
On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
That is such good news.  What(low cost)  hardware would this
development be used on to support the developers with
testing/debugging and maybe even development ?
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>  (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel
ADAT modules (32 channels) to a PC under Ubuntu via AVB with low
latency. The only option to get this done under Windows is a
Focursrite DANTE based Rednet 3 right now because Thunderbolt is not
really available there as well. Plan to get Rednet3,  but that does
not solve the Linux environment which I prefer. Would love to be
able to use the Rednet 3 under Linux but since DANTE is proprietary
, so unlikely.
  [a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
  [b[ Bitwig  supporting LV2 plugins.
With those two,  the Linux Audio environment would be perfect and
the world a better place.
*(Apology for the re-sends and ignore the previous edits. Web based
Gmail is such a annoyance and un-logically structured)*
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
happy musicmaker
2017-09-30 04:12:40 UTC
Permalink
I read more negative messages about MOTU. I use an Focusrite 18i20
extended with a Scarllett Octpore over ADAT with WORD or ADAT clock for 16
channels under Ubuntu 17.04 with great working ALSA mixer using sample
rates from 44.1 to 96 Khz. (though with high USB latency). Planning to get
a Rednet 3 (DANTE) and if this would/should work with this solution I would
be very exited and definitely consider to get one sooner as planned. My
switch supports IGMPv2 multicast. (Cisco 2960G8-TCL). I am familiar with
Linux coding but don't know how to recompile ALSA and install/upgrade it to
test on an existing kernel. A 210 card I can get easily. There are some
different I210 card versions it seems, any recommendations ? Coding wise,
I wish to find time to support the FR Scarlett Gen 2 ALSA mixer on Linux
as a lot of people want it due to it's much low USB latency.
Thanks
With an Intel I210 NIC you can already have AVB in combination with Jack.
But you have to do some coding yourself to fit your purposes..
I would never recommend buying MOTU.
BR,
Ck
Post by happy musicmaker
MOTU just released the 828es with AVB and USB standard compliant and two
ADAT I/O and Web based (not ALSA) mixer. That would be, for now, the
ultimate (AVB) interface for Linux, if it works.
On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker <
That is such good news. What(low cost) hardware would this
development be used on to support the developers with
testing/debugging and maybe even development ?
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg> (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel
ADAT modules (32 channels) to a PC under Ubuntu via AVB with low
latency. The only option to get this done under Windows is a
Focursrite DANTE based Rednet 3 right now because Thunderbolt is not
really available there as well. Plan to get Rednet3, but that does
not solve the Linux environment which I prefer. Would love to be
able to use the Rednet 3 under Linux but since DANTE is proprietary
, so unlikely.
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and
the world a better place.
*(Apology for the re-sends and ignore the previous edits. Web based
Gmail is such a annoyance and un-logically structured)*
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Christoph Kuhr
2017-10-01 08:32:31 UTC
Permalink
A few years back there had been a AES67/Ravenna implementation. But the
developer and ALX Networks could not agree on the license. The developer
wanted to publish it under GPL, which ALX Networks did not want. So the
implementation was dumped. Well, that is the story how I know it.
The developer was Florian Faber, but he is no member of the jack-devel
or linux-devel list anymore. Perhapes, he might have some useful
insights, if you manage to find a contact. ;-)
There are some different I210 card versions
it seems, any recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.



BR,
CK
With an Intel I210 NIC you can already have AVB in combination with
Jack. But you have to do some coding yourself to fit your purposes..
I would never recommend buying MOTU.
BR,
Ck
MOTU just released the 828es with AVB and USB standard compliant
and two ADAT I/O and Web based (not ALSA) mixer. That would be,
for now, the ultimate (AVB)  interface for Linux,  if it works.
On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
    That is such good news.  What(low cost)  hardware would this
    development be used on to support the developers with
    testing/debugging and maybe even development ?
    * MOTU LP32 (Preferred)
    * MiniDSP
https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
    <https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>>  (I think
    MOTU's switch uses midDSP switch hardware)
    I hope someday it will be possible to connect 4 or more 8
channel
    ADAT modules (32 channels) to a PC under Ubuntu via AVB
with low
    latency. The only option to get this done under Windows is a
    Focursrite DANTE based Rednet 3 right now because
Thunderbolt is not
    really available there as well. Plan to get Rednet3,  but
that does
    not solve the Linux environment which I prefer. Would love
to be
    able to use the Rednet 3 under Linux but since DANTE is
proprietary
    , so unlikely.
       [a] Multi (16+) channel low latency audio I/O using ADAT
audio AD/DA
       [b[ Bitwig  supporting LV2 plugins.
    With those two,  the Linux Audio environment would be
perfect and
    the world a better place.
    *(Apology for the re-sends and ignore the previous edits.
Web based
    Gmail is such a annoyance and un-logically structured)*
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Philippe Bekaert
2017-10-02 10:12:34 UTC
Permalink
Thanks all for these helpful comments!
I’ve been studying the last days, and I am studying more.

I downloaded merging technologies free AES67 virtual sound card for mac already, as well as the Dante Via from audinate (59USD). The latter is also capable of functioning as a master clock on the network I understand. That will do for the testing and development at this time. Thanks for the many other suggestions you made. The gear I found before was more expensive (e.g. digigram has a -very well reputed- ravenna sound card with linux support for about 2K).

There is indeed a Ravenna reference implementation with linux support by ALC NetworX. I’m waiting for information regarding conditions for obtaining, using, distributing it. I’m also in contact with people at Merging regarding their VSC driver in progress for Linux.

I contacted audinate regarding AES67 patent claims.

As said, I’m not really considering implementing AES67 as a virtual sound card driver - I prefer to stay clear of kernel space development. Instead, Im aiming for a jack client application, and perhaps a jack audio driver (like the net drivers). The latter allow to have jack running at AES67 clock, and being fully transparent (no sample rate conversion). But the former, a client application, is probably better if you just want to receive and monitor / send AES67 on / from a computer having a sound card already.

Thanks also for the hint about the zita resampler library.

I’m keeping you informed about progress and findings.

Best,

Philippe.
A few years back there had been a AES67/Ravenna implementation. But the developer and ALX Networks could not agree on the license. The developer wanted to publish it under GPL, which ALX Networks did not want. So the implementation was dumped. Well, that is the story how I know it.
The developer was Florian Faber, but he is no member of the jack-devel or linux-devel list anymore. Perhapes, he might have some useful insights, if you manage to find a contact. ;-)
Wargreen
2017-10-02 15:58:02 UTC
Permalink
Hi jack's list,

This is a very usefull project, thank you for this !
Maybe a master / slave driver can be good for use as master clock or
stick to the soundcard's clock ? Or as an internal ?

If needed for tests, i can look to access to some dante networks.

Wargreen
Post by Philippe Bekaert
Thanks all for these helpful comments!
I’ve been studying the last days, and I am studying more.
I downloaded merging technologies free AES67 virtual sound card for mac already, as well as the Dante Via from audinate (59USD). The latter is also capable of functioning as a master clock on the network I understand. That will do for the testing and development at this time. Thanks for the many other suggestions you made. The gear I found before was more expensive (e.g. digigram has a -very well reputed- ravenna sound card with linux support for about 2K).
There is indeed a Ravenna reference implementation with linux support by ALC NetworX. I’m waiting for information regarding conditions for obtaining, using, distributing it. I’m also in contact with people at Merging regarding their VSC driver in progress for Linux.
I contacted audinate regarding AES67 patent claims.
As said, I’m not really considering implementing AES67 as a virtual sound card driver - I prefer to stay clear of kernel space development. Instead, Im aiming for a jack client application, and perhaps a jack audio driver (like the net drivers). The latter allow to have jack running at AES67 clock, and being fully transparent (no sample rate conversion). But the former, a client application, is probably better if you just want to receive and monitor / send AES67 on / from a computer having a sound card already.
Thanks also for the hint about the zita resampler library.
I’m keeping you informed about progress and findings.
Best,
Philippe.
A few years back there had been a AES67/Ravenna implementation. But the developer and ALX Networks could not agree on the license. The developer wanted to publish it under GPL, which ALX Networks did not want. So the implementation was dumped. Well, that is the story how I know it.
The developer was Florian Faber, but he is no member of the jack-devel or linux-devel list anymore. Perhapes, he might have some useful insights, if you manage to find a contact. ;-)
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
happy musicmaker
2017-10-03 06:56:33 UTC
Permalink
I am considering to get a pair of these. Intel Ethernet Server Adapter
I210T1, single port PCI-e (with 802.1qav support).

[image: Inline image 1]

On Mon, Oct 2, 2017 at 6:12 PM, Philippe Bekaert <
Post by Philippe Bekaert
Thanks all for these helpful comments!
I’ve been studying the last days, and I am studying more.
I downloaded merging technologies free AES67 virtual sound card for mac
already, as well as the Dante Via from audinate (59USD). The latter is also
capable of functioning as a master clock on the network I understand. That
will do for the testing and development at this time. Thanks for the many
other suggestions you made. The gear I found before was more expensive
(e.g. digigram has a -very well reputed- ravenna sound card with linux
support for about 2K).
There is indeed a Ravenna reference implementation with linux support by
ALC NetworX. I’m waiting for information regarding conditions for
obtaining, using, distributing it. I’m also in contact with people at
Merging regarding their VSC driver in progress for Linux.
I contacted audinate regarding AES67 patent claims.
As said, I’m not really considering implementing AES67 as a virtual sound
card driver - I prefer to stay clear of kernel space development. Instead,
Im aiming for a jack client application, and perhaps a jack audio driver
(like the net drivers). The latter allow to have jack running at AES67
clock, and being fully transparent (no sample rate conversion). But the
former, a client application, is probably better if you just want to
receive and monitor / send AES67 on / from a computer having a sound card
already.
Thanks also for the hint about the zita resampler library.
I’m keeping you informed about progress and findings.
Best,
Philippe.
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But the
developer and ALX Networks could not agree on the license. The developer
wanted to publish it under GPL, which ALX Networks did not want. So the
implementation was dumped. Well, that is the story how I know it.
Post by Christoph Kuhr
The developer was Florian Faber, but he is no member of the jack-devel
or linux-devel list anymore. Perhapes, he might have some useful insights,
if you manage to find a contact. ;-)
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
happy musicmaker
2017-10-03 07:19:07 UTC
Permalink
This post might be inappropriate. Click to display it.
Ralf Mardorf
2017-10-03 08:01:07 UTC
Permalink
Post by happy musicmaker
Bugger, according to this, the I210T1 requires a PCI 2.1 slot. Mine is
just a 2.0.
https://communities.intel.com/thread/108269. The Intel I210T1 spec
states "The interface only supports the PCIe v2.1 (2.5GT/s) rate and
is configured to x1."
So, this seems to be a showstopper. Most new MB are already PCI Gen 3,
like this
https://www.msi.com/Motherboard/Z77AG45_Thunderbolt/Specification,
So if it ONLY supports PCI 2.1 ... (?) Would the card work on 2.0 and 3.0 ?
https://en.wikipedia.org/wiki/PCI_Express#PCI_Express_2.1
https://en.wikipedia.org/wiki/PCI_Express#PCI_Express_3.0

Let alone that you could put the x1 card into any other slot, e.g. x16.
Chris Caudle
2017-10-03 14:18:33 UTC
Permalink
Post by happy musicmaker
Bugger, according to this, the I210T1 requires a PCI 2.1 slot. Mine is
just a 2.0.
PCIe 2.1 was basically an addendum to add additional features, all
compliant PCIe devices are required to be backwards compatible with older
slots. The PCIe version listed on the specification is the highest version
that it can support with full features, not a strict list.
Note also that there seems to be a mistake in the specification, PCIe 2
generation should be 5GT/s not 2.5GT/s. Possibly the device supports the
register set and software features of PCIe 2.1 but only runs at gen 1.0
speed of 2.5GT/s, but that would be unusual.

I would check the list at linuxptp.sourceforge.com for recommended
adapters. The linuxptp project takes advantage of the latest linux kernel
features and does not limit itself to interfaces available in other OS
like ptpd. I don't know if that provides any performance advantage or
not, linuxptp project claims that using linux specific kernel API is
better than using generic posix API.

This is the list of drivers which support hardware time stamping in the
MAC layer, but you have to look at the details for the card you want to
buy. For example, the tg3 driver supports hardware timestamping on
Broadcom Tigon based cards, but I have a broadcom NIC which does not
support hardware timestamping, only software.

Note that if you have a Windows installation and want to use the ALC
Windows virtual sound card you will need an adapater with an 82574L
controller.

I apologize for the poor formatting, I do not want to use HTML email for
the mailing list, see the linuxptp web page for an easier to read table
format.

5.3.2 Hardware Timestamping - MAC
Driver Hardware Version
amd-xgbe AMD 10GbE Ethernet Soc 3.17
bfin_mac Analog Blackfin 3.8
bnx2x Broadcom NetXtremeII 10G 3.18
cpts Texas Instruments am335x 3.8
e1000e Intel 82574, 82583 3.9
fm10k Intel FM10000 3.18
fec Freescale i.mx6 3.8
gianfar Freescale eTSEC PowerPC 3.0
i40e Intel XL710 Family 3.14
igb Intel 82576, 82580 3.5
ixgbe Intel 82599 3.5
mlx4 Mellanox 40G PCI 3.14
ptp_ixp46x Intel IXP465 3.0
ptp_phc Lapis EG20T PCH 3.5
sfc Solarflare SFC9000 3.7
stmmac STM Synopsys IP Core 3.10
tg3 Broadcom Tigon3 PCI 3.8
tilegx Tilera GBE/XGBE 3.12
--
Chris Caudle
Philippe Bekaert
2017-10-03 14:47:29 UTC
Permalink
The correct link for linuxptp seems to be
http://linuxptp.sourceforge.net

Anyways, happy musicmaker : you may just want to try first with your current network adapter lacking hardware time stamping.
ptpd reports clock synchronisation accuracy in the order of microseconds.
Others report up to 100 microseconds accuracy in absense of hardware time stamping and on a loaded network.
Thats still only 5 audio samples and the latency of your audio card is probably a lot larger than that (miliseconds at least).
You’re probably not doing highly time critical work either.
No need to rush for that (web) shop right away …

Best,

Philippe.
Post by Chris Caudle
Post by happy musicmaker
Bugger, according to this, the I210T1 requires a PCI 2.1 slot. Mine is
just a 2.0.
PCIe 2.1 was basically an addendum to add additional features, all
compliant PCIe devices are required to be backwards compatible with older
slots. The PCIe version listed on the specification is the highest version
that it can support with full features, not a strict list.
Note also that there seems to be a mistake in the specification, PCIe 2
generation should be 5GT/s not 2.5GT/s. Possibly the device supports the
register set and software features of PCIe 2.1 but only runs at gen 1.0
speed of 2.5GT/s, but that would be unusual.
I would check the list at linuxptp.sourceforge.com for recommended
adapters. The linuxptp project takes advantage of the latest linux kernel
features and does not limit itself to interfaces available in other OS
like ptpd. I don't know if that provides any performance advantage or
not, linuxptp project claims that using linux specific kernel API is
better than using generic posix API.
This is the list of drivers which support hardware time stamping in the
MAC layer, but you have to look at the details for the card you want to
buy. For example, the tg3 driver supports hardware timestamping on
Broadcom Tigon based cards, but I have a broadcom NIC which does not
support hardware timestamping, only software.
Note that if you have a Windows installation and want to use the ALC
Windows virtual sound card you will need an adapater with an 82574L
controller.
I apologize for the poor formatting, I do not want to use HTML email for
the mailing list, see the linuxptp web page for an easier to read table
format.
5.3.2 Hardware Timestamping - MAC
Driver Hardware Version
amd-xgbe AMD 10GbE Ethernet Soc 3.17
bfin_mac Analog Blackfin 3.8
bnx2x Broadcom NetXtremeII 10G 3.18
cpts Texas Instruments am335x 3.8
e1000e Intel 82574, 82583 3.9
fm10k Intel FM10000 3.18
fec Freescale i.mx6 3.8
gianfar Freescale eTSEC PowerPC 3.0
i40e Intel XL710 Family 3.14
igb Intel 82576, 82580 3.5
ixgbe Intel 82599 3.5
mlx4 Mellanox 40G PCI 3.14
ptp_ixp46x Intel IXP465 3.0
ptp_phc Lapis EG20T PCH 3.5
sfc Solarflare SFC9000 3.7
stmmac STM Synopsys IP Core 3.10
tg3 Broadcom Tigon3 PCI 3.8
tilegx Tilera GBE/XGBE 3.12
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Chris Caudle
2017-10-21 14:13:03 UTC
Permalink
I’m also in contact with people at
Merging regarding their VSC driver in progress for Linux.
Did you get a copy of the ALSA driver? The current git head does not
compile, I waited to see if merging would correct that on their own, but
still not corrected after a month, so I need to ask what is happening
there. Not encouraging that it is actually getting any attention if the
source can go more than a month in a non-buildable state.
I'm aiming for a jack client application, and perhaps a jack audio driver
(like the net drivers). The latter allow to have jack running at AES67
clock, and being fully transparent (no sample rate conversion). But the
former, a client application, is probably better if you just want to
receive and monitor / send AES67 on / from a computer having a sound card
already.
I recommend a jack audio driver. If you want to monitor from a local
sound card you can always load zita-j2a and zita-a2j resampling bridges,
that work has been done so no need to implement twice what Fons has
already implemented. The advantages of a net driver is that you can in
principle collect streams from different devices that are in the same
clock domain and have a large virtual sound card. For example, in a home
recording environment you could have a Ravenna output device in your room
with a computer, have a Ravenna in/out device in a different room with
someone playing keyboards, and a Ravenna in/out device in the house large
room playing guitar, and all three of those physically separated devices
could be treated as one large audio interface.
I am not sure if jackd will let a driver load and then change the number
of ports at a later time, so how configuration would work is a task that
needs to be investigated early (e.g. would you have to discover and
configure Ravenna streams first, then load the net driver, or could the
net driver be loaded with some arbitrary number of ports declared to
jackd, and various Ravenna streams connected and disconnected from those
declared ports at run time).

I am still struggling to find reasonable cost network connected
interfaces. The small device from Hasseb I linked last time is reasonable
cost, but very low feature, I would prefer at least a duplex stereo
device. Focusrite have a new two channel Dante device which could run in
AES67 mode, but it is output only, and I think is around US$400. The 4
input 2 output Cymatic device is still not available yet, and even though
the 24 channel Cymatic device has reduced price by 50% lately, that is the
base USB version only, so by the time you purchase the Ravenna option card
it is still around US$1000. Not a bad price for 24 channels, but still
could be considered quite a lot to spend on a hobby investigation project.

If a Windows computer is available, the Lawo R3lay virtual sound card for
Windows is the best option to get started. I tried it and was able to
send audio between two Windows laptops. You will need a PTP master on the
network, that VSC will not act as clock master, but I am running a
BeagleBone Black as PTP master (uses chronyd to sync time to ntp, then
provides the ntp time to the network using linuxptp). You could also use
your existing linux machine to act at PTP master, it would just have more
jitter in the PTP performance if you do not have hardware timestamping
capability (the BeagleBone has hardware timestamp in the MAC layer but not
the phy, not ideal but still fairly high performance).
--
Chris Caudle
happy musicmaker
2017-10-23 03:31:47 UTC
Permalink
For what gives, and perhaps even not useful for this and more for AVB, but
ordered two I210T1 each $44 from Amazon just for testing peer to peer. My
plan is still a Rednet 3 as I see it the only option for Linux now to
create a multi-channel network for the studio with the current ADAT's
DAC/ADCs's on hand. (Don't see Thunderbolt happening to become mainstream
on Windows and for Linux perhaps it will never happen) I am not sure what
AES67 FR implemented in the Red-net 3 firmware (Bonjour or any other
discovery protocol). Still learning and reading lots of AE67 material and
you-tube got some good video's as well.
Post by Chris Caudle
Post by Philippe Bekaert
I’m also in contact with people at
Merging regarding their VSC driver in progress for Linux.
Did you get a copy of the ALSA driver? The current git head does not
compile, I waited to see if merging would correct that on their own, but
still not corrected after a month, so I need to ask what is happening
there. Not encouraging that it is actually getting any attention if the
source can go more than a month in a non-buildable state.
Post by Philippe Bekaert
I'm aiming for a jack client application, and perhaps a jack audio driver
(like the net drivers). The latter allow to have jack running at AES67
clock, and being fully transparent (no sample rate conversion). But the
former, a client application, is probably better if you just want to
receive and monitor / send AES67 on / from a computer having a sound card
already.
I recommend a jack audio driver. If you want to monitor from a local
sound card you can always load zita-j2a and zita-a2j resampling bridges,
that work has been done so no need to implement twice what Fons has
already implemented. The advantages of a net driver is that you can in
principle collect streams from different devices that are in the same
clock domain and have a large virtual sound card. For example, in a home
recording environment you could have a Ravenna output device in your room
with a computer, have a Ravenna in/out device in a different room with
someone playing keyboards, and a Ravenna in/out device in the house large
room playing guitar, and all three of those physically separated devices
could be treated as one large audio interface.
I am not sure if jackd will let a driver load and then change the number
of ports at a later time, so how configuration would work is a task that
needs to be investigated early (e.g. would you have to discover and
configure Ravenna streams first, then load the net driver, or could the
net driver be loaded with some arbitrary number of ports declared to
jackd, and various Ravenna streams connected and disconnected from those
declared ports at run time).
I am still struggling to find reasonable cost network connected
interfaces. The small device from Hasseb I linked last time is reasonable
cost, but very low feature, I would prefer at least a duplex stereo
device. Focusrite have a new two channel Dante device which could run in
AES67 mode, but it is output only, and I think is around US$400. The 4
input 2 output Cymatic device is still not available yet, and even though
the 24 channel Cymatic device has reduced price by 50% lately, that is the
base USB version only, so by the time you purchase the Ravenna option card
it is still around US$1000. Not a bad price for 24 channels, but still
could be considered quite a lot to spend on a hobby investigation project.
If a Windows computer is available, the Lawo R3lay virtual sound card for
Windows is the best option to get started. I tried it and was able to
send audio between two Windows laptops. You will need a PTP master on the
network, that VSC will not act as clock master, but I am running a
BeagleBone Black as PTP master (uses chronyd to sync time to ntp, then
provides the ntp time to the network using linuxptp). You could also use
your existing linux machine to act at PTP master, it would just have more
jitter in the PTP performance if you do not have hardware timestamping
capability (the BeagleBone has hardware timestamp in the MAC layer but not
the phy, not ideal but still fairly high performance).
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Chris Caudle
2017-10-23 03:39:47 UTC
Permalink
Post by happy musicmaker
plan is still a Rednet 3
Keep in mind that Dante was originally using a different clocking scheme,
so original Dante protocol is not compatible with AES67, only the new
updated protocol. Make sure that the new AES67 firmware is available for
Rednet 3 before you buy.
Post by happy musicmaker
AES67 FR implemented in the Red-net 3 firmware (Bonjour or any other
discovery protocol).
Not sure what you were meaning by "FR," but AES67 essentially gave up on
discovery, you have to use external means to configure the different
devices. Basically AES67 just describes the least common denominator of
several different network protocols, there is no device which has "native"
AES67 if you will, but you can configure a Ravenna device to use only the
subset of features covered in AES67, configure a Dante device to use the
subset of features covered in AES67, and then configure the two devices
with the network addresses and ports to find each other and they can
exchange data.
--
Chris Caudle
Chris Caudle
2017-10-23 16:09:06 UTC
Permalink
ALC Networx and audinate (several times) concerning patent issues
My limited understanding is that the original Dante protocol is or was
covered by a patent regarding the non-standard clocking method they used,
but Ravenna specifically uses only IEEE and IETF specifications which
should be not covered by any current patents, with the exception of
features which should be part of the hardware (e.g. if the Ethernet
adapter vendor is licensing a patent for some hardware feature we should
not need to care). I have not heard of any patents asserted against IEEE
1588-2008, and protocols like RTP and RTCP have been implemented for many
years by browsers and media players, so I think there should be no patents
there.
many choices for the implementation of each of the required components
(full implementation generic libraries, or ad hoc pieces of open source
My preference would be re-use anything available, days are too short to
re-implement software which is already working. That presumes that a
library for what is needed is well maintained, and that the function is
not so simple that understanding how to use the library is not more work
than just implementing for the jack driver.

One thing that will influence what libraries you may choose to use is
whether you want to make the software cross platform or linux only. My
thinking there is that there are virtual sound card implementations for
Windows and Mac OS already, so jack on Windows and Mac OS can use the
existing sound system interface.
If you implement as linux only, you could potentially take certain
shortcuts such as requiring that the user install linuxptp and synchronize
the system clock to the audio PTP domain first. That way you could use
the system clock as the clock for scheduling the net driver.
Right now, I'm using the free merging AES67 sound card driver on a
macbook pro to generate AES67 streams, and later also to receive.
I do not have a Mac, so I did not even think of that. That is a good
choice, essentially the equivalent of the free Lawo R3lay driver I was
testing on Windows. The only disadvantage I can see is the driver is
limited in what buffer sizes and sample rates it supports, so you can only
test a subset of what is possible to support, but definitely should allow
getting all the basic work completed with just software implementations on
each end.
I'm running ptp4l (hardware timestamping support, on a server) or ptpd
(if you don't have hw ts - on my laptop)
I believe ptp4l should also support software timestamp.
I can run ptp4l on my workstation to synchronize to my BeagleBone ptp
master, and ethtool reports that there is no PTP hardware clock available:

Time stamping parameters for enp3s4f0:
Capabilities:
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)

I am continuing to copy the jack-devel mail list for now, hopefully there
are some others who will be interested in participating, if not eventually
we can take this to a private distribution until something is ready for
wider testing.
--
Chris Caudle
Chris Caudle
2017-10-23 20:26:33 UTC
Permalink
wireshark reveals that dante is using ptp v1 - it's not that
non-standard.
Correct, I have not looked up the Audinate patent(s) yet, I do not know
what was unique enough to award a patent. In any case ALC Networx did not
seem to think that the Ravenna approach of using PTPv2 (IEEE 1588-2008)
for synchronization and RTP/RTCP (IEEE 1733-2011 and IETF RFC3550 and
RFC3650) for media streams would be covered by any patents.
Especially rtp is not difficult : it's just one packet format, and we
need none of the special features, essentially just the time stamp
in the header and the audio data.
Yes, time stamp calculations and latency adjustments seemed like the only
part that would possibly be a little tricky. The rest seems like just
manipulating sample values to get into the correct order in the packet.
Jack uses floating point for sample format and RTP uses integers, so the
usual conversion between integer and floating point that you would do for
sending samples to a hardware sound card applies.
I'm sticking with linux in the first place, but using platform
independent tools whereever available.
Hence also my consideration of the asio C++11 library for networking
support.
OK, the first time I misread that as an ASIO library, i.e. the Steinberg
designed Windows specific multi-channel audio specification, not asio C++
library for asynchronous I/O.
I checked my fedora installation and that is easily available as the
asio-devel package. I think libasio-dev is the equivalent in debian.
Seems that should not be a problem for any recent distribution.
Actually, now that I look at the details that seems to be just headers,
I'm not sure where the actual libraries are implemented. Something to
investigate later.
I'm considering to have a user set up system time synchronisation
with the audio network clock master and use system time as
reference indeed, as you also proposed.
One thing I do not know is what the clock will be set to using one of the
standalone audio devices as the PTP master. I'm not sure if those devices
have a battery backed clock, so potentially if you set your system clock
to the PTP clock in a network which only contains a Ravenna device for
example, your system clock could jump to some unexpected value,
potentially far in the past. Just something to consider for documentation
purposes for the moment, hopefully I will find a way to get access to some
hardware for testing.
It won't work if you have different audio devices synchronised with
different master clocks
That is always the case, whether using network audio, USB, or AES/EBU or
S/PDIF connections, so again I think just a note for the documentation.
Typically any devices which are on the same network segment or VLAN will
end up using the same master clock because of the PTP best master clock
algorithm so in practical installations should not be a problem. I think
you would have to specifically change the default clock domain from clock
0 to some other value to have that problem.

A second level of consideration is that two devices which are using the
same master clock could still be configured to use different sample rates,
so those two devices could still not be used together as a single
aggregate audio device. That could be manually checked at the beginning,
but eventually should be part of whatever configuration method exists,
compatibility of stream parameters should be verified before those streams
are allowed to be configured together as part of the aggregate device.
--
Chris Caudle
Happy
2017-12-20 06:45:58 UTC
Permalink
This post might be inappropriate. Click to display it.
Christoph Kuhr
2017-12-20 09:37:46 UTC
Permalink
Hi,

have a look at:

https://github.com/AVnu/OpenAvnu

There you can find the entire AVB driver stack and subsystem. Along with
some Gstreamer and Jack Audio examples.

BR,
CK
Post by Happy
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon).
Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus only
using part of the slot). Initially windows reported an error and it did
not work. Went back to Ubuntu 17.10 on the same machine and it worked
fine. (Same result as another person before me). Disabled the internal
NIC and started Windows again. Voila, it worked ! Re-enabled the
on-board NIC and it kept Working in windows. Just for reference.  Don't
have a AVB audio device so cannot really test them. Looking if there is
any AVB test software out there to use these two cards to transmit AVB
based audio from one to the other.
From talking to Focusrite regarding AES67 and the Rednet series and
firmware support, got the following:  "With regards to AES67
compatibility, this is possible for devices using the 'Brooklyn 2' Dante
chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though it's
possible to upgrade to a Brooklyn 2 (this would be chargeable). All of
our devices using Brooklyn 2 modules have AES67 compliance following the
latest firmware update available from RedNet Control"  (Focusrite
Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP  / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully
suppliers will support some kind of new standard in the future for that
as well ( HTML XML, JSON  or other open messaging over IP to configure
the unit). The Rednet3 will keep the routing/configuration after power
cycling thus until then that should be done under Windows.
Looking forward on the progress  of this project !
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But
the developer and ALX Networks could not agree on the license. The
developer wanted to publish it under GPL, which ALX Networks did not
want. So the implementation was dumped. Well, that is the story how I
know it.
The developer was Florian Faber, but he is no member of the jack-devel
or linux-devel list anymore. Perhapes, he might have some useful
insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any
recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.
BR,
CK
On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr
    With an Intel I210 NIC you can already have AVB in combination with
    Jack. But you have to do some coding yourself to fit your purposes..
    I would never recommend buying MOTU.
    BR,
    Ck
        MOTU just released the 828es with AVB and USB standard compliant
        and two ADAT I/O and Web based (not ALSA) mixer. That would be,
        for now, the ultimate (AVB)  interface for Linux,  if it works.
        On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
             That is such good news.  What(low cost)  hardware would
this
             development be used on to support the developers with
             testing/debugging and maybe even development ?
             * MOTU LP32 (Preferred)
             * MiniDSP
        https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
             MOTU's switch uses midDSP switch hardware)
             I hope someday it will be possible to connect 4 or more 8
        channel
             ADAT modules (32 channels) to a PC under Ubuntu via AVB
        with low
             latency. The only option to get this done under Windows
is a
             Focursrite DANTE based Rednet 3 right now because
        Thunderbolt is not
             really available there as well. Plan to get Rednet3,  but
        that does
             not solve the Linux environment which I prefer. Would love
        to be
             able to use the Rednet 3 under Linux but since DANTE is
        proprietary
             , so unlikely.
                [a] Multi (16+) channel low latency audio I/O using ADAT
        audio AD/DA
                [b[ Bitwig  supporting LV2 plugins.
             With those two,  the Linux Audio environment would be
        perfect and
             the world a better place.
             *(Apology for the re-sends and ignore the previous edits.
        Web based
             Gmail is such a annoyance and un-logically structured)*
        _______________________________________________
        Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
    _______________________________________________
    Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Christoph Kuhr
2017-12-20 10:22:41 UTC
Permalink
PS
The thesis includes an AES67 controller based on Python3, Websockets and JSON objects. As discovery library, Avahi shall be used. All setup as a Docker container. Thus, it should be platform independent.
Post by Christoph Kuhr
Hi,
https://github.com/AVnu/OpenAvnu
There you can find the entire AVB driver stack and subsystem. Along with
some Gstreamer and Jack Audio examples.
BR,
CK
Post by Happy
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon).
Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus
only
Post by Happy
using part of the slot). Initially windows reported an error and it
did
Post by Happy
not work. Went back to Ubuntu 17.10 on the same machine and it worked
fine. (Same result as another person before me). Disabled the
internal
Post by Happy
NIC and started Windows again. Voila, it worked ! Re-enabled the
on-board NIC and it kept Working in windows. Just for reference. 
Don't
Post by Happy
have a AVB audio device so cannot really test them. Looking if there
is
Post by Happy
any AVB test software out there to use these two cards to transmit
AVB
Post by Happy
based audio from one to the other.
From talking to Focusrite regarding AES67 and the Rednet series and
firmware support, got the following:  "With regards to AES67
compatibility, this is possible for devices using the 'Brooklyn 2'
Dante
Post by Happy
chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though it's
possible to upgrade to a Brooklyn 2 (this would be chargeable). All
of
Post by Happy
our devices using Brooklyn 2 modules have AES67 compliance following
the
Post by Happy
latest firmware update available from RedNet Control"  (Focusrite
Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP  / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully
suppliers will support some kind of new standard in the future for
that
Post by Happy
as well ( HTML XML, JSON  or other open messaging over IP to
configure
Post by Happy
the unit). The Rednet3 will keep the routing/configuration after
power
Post by Happy
cycling thus until then that should be done under Windows.
Looking forward on the progress  of this project !
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But
the developer and ALX Networks could not agree on the license. The
developer wanted to publish it under GPL, which ALX Networks did not
want. So the implementation was dumped. Well, that is the story how
I
Post by Happy
Post by Christoph Kuhr
know it.
The developer was Florian Faber, but he is no member of the
jack-devel
Post by Happy
Post by Christoph Kuhr
or linux-devel list anymore. Perhapes, he might have some useful
insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any
recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.
BR,
CK
On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr
    With an Intel I210 NIC you can already have AVB in combination
with
Post by Happy
Post by Christoph Kuhr
    Jack. But you have to do some coding yourself to fit your
purposes..
Post by Happy
Post by Christoph Kuhr
    I would never recommend buying MOTU.
    BR,
    Ck
        MOTU just released the 828es with AVB and USB standard
compliant
Post by Happy
Post by Christoph Kuhr
        and two ADAT I/O and Web based (not ALSA) mixer. That would
be,
Post by Happy
Post by Christoph Kuhr
        for now, the ultimate (AVB)  interface for Linux,  if it
works.
Post by Happy
Post by Christoph Kuhr
        On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
             That is such good news.  What(low cost)  hardware
would
Post by Happy
Post by Christoph Kuhr
this
             development be used on to support the developers with
             testing/debugging and maybe even development ?
             * MOTU LP32 (Preferred)
             * MiniDSP
        https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
             MOTU's switch uses midDSP switch hardware)
             I hope someday it will be possible to connect 4 or
more 8
Post by Happy
Post by Christoph Kuhr
        channel
             ADAT modules (32 channels) to a PC under Ubuntu via
AVB
Post by Happy
Post by Christoph Kuhr
        with low
             latency. The only option to get this done under
Windows
Post by Happy
Post by Christoph Kuhr
is a
             Focursrite DANTE based Rednet 3 right now because
        Thunderbolt is not
             really available there as well. Plan to get Rednet3, 
but
Post by Happy
Post by Christoph Kuhr
        that does
             not solve the Linux environment which I prefer. Would
love
Post by Happy
Post by Christoph Kuhr
        to be
             able to use the Rednet 3 under Linux but since DANTE
is
Post by Happy
Post by Christoph Kuhr
        proprietary
             , so unlikely.
                [a] Multi (16+) channel low latency audio I/O using
ADAT
Post by Happy
Post by Christoph Kuhr
        audio AD/DA
                [b[ Bitwig  supporting LV2 plugins.
             With those two,  the Linux Audio environment would be
        perfect and
             the world a better place.
             *(Apology for the re-sends and ignore the previous
edits.
Post by Happy
Post by Christoph Kuhr
        Web based
             Gmail is such a annoyance and un-logically
structured)*
Post by Happy
Post by Christoph Kuhr
        _______________________________________________
        Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
    _______________________________________________
    Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
--
Diese Nachricht wurde von meinem Android-GerÀt mit K-9 Mail gesendet.
zmlopez
2018-01-16 09:50:32 UTC
Permalink
Very interesting.
I'm working in something similar. My concept is to use gstreamer plugins for
AES67 (gstreamer could already use ptp clocks), and AES70 (OCA) for control
and discovery:
http://www.aes.org/publications/standards/search.cfm?docID=103
https://github.com/DeutscheSoft/OCA.js/tree/master




--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
Philippe BEKAERT
2018-01-16 15:16:56 UTC
Permalink
Ok great! Thanks for letting me know.
I’m not considering AES70 at this time.
How mature is the gstreamer AES67 support at this time? Do you have any further information?

I also heard about efforts to support AES67 (as part of SMPTE 2110) in ffmpeg, but no idea about current status either.
https://tech.ebu.ch/docs/events/opensource17/presentations/SMPTE2110-ffmpeg.pdf <https://tech.ebu.ch/docs/events/opensource17/presentations/SMPTE2110-ffmpeg.pdf>

Best,

Philippe.

Philippe BEKAERT
Hoogleraar - projectleider
Universiteit Hasselt - Expertisecentrum voor Digitale Media
Wetenschapspark 2, 3590 Diepenbeek, Belgie
www.edm.uhasselt.be
+32 11 268411
Post by zmlopez
Very interesting.
I'm working in something similar. My concept is to use gstreamer plugins for
AES67 (gstreamer could already use ptp clocks), and AES70 (OCA) for control
http://www.aes.org/publications/standards/search.cfm?docID=103
https://github.com/DeutscheSoft/OCA.js/tree/master
--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
zmlopez
2018-01-17 13:54:32 UTC
Permalink
There is something explained on this link:

https://www.collabora.com/news-and-blog/blog/2017/04/25/receiving-an-aes67-stream-with-gstreamer/

I think that the best way is to use rtsp server implementation to receive
the sdp




--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
zmlopez
2018-01-17 13:56:29 UTC
Permalink
More links about ptp support in gstreamer:

https://coaxion.net/blog/2015/05/ptp-network-clock-support-in-gstreamer/

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstPtpClock.html

https://coaxion.net/blog/2017/04/rtp-for-broadcasting-over-ip-use-cases-in-gstreamer-ptp-rfc7273-for-ravenna-aes67-smpte-2022-smpte-2110/





--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
Chris Caudle
2018-01-17 18:22:19 UTC
Permalink
One thing which is not clear to me is what would happen if more than one
piece of software is attempting to capture PTP packets. For example, say
the machine is running linuxptp to synchronize the system clock to ptp,
what happens when you load the gstreamer ptp module? Does the gstreamer
module not get any ptp packets? Or starts stealing from the linuxptp? Or
both linuxptp and gstreamer get the same packets?

The linuxptp implementation can use the timestamp capability of the NIC,
before I go off and dig through the gstreamer source, anyone know if
gstreamer will do that as well?
--
Chris Caudle
zmlopez
2018-01-17 19:39:36 UTC
Permalink
I think that ptp traffic is udp multicast. If the programs use SO_REUSEADDR
before binding, I think that more than one program could receive the
packets, and I see that flag in the source code.





--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
Chris Caudle
2018-01-16 17:29:35 UTC
Permalink
Post by zmlopez
My concept is to use gstreamer plugins for
AES67 (gstreamer could already use ptp clocks)
When did gstreamer get support for using ptp? Do you know the best place
to find documentation on that? I never saw that news.
--
Chris Caudle
Christoph Kuhr
2017-12-20 09:47:37 UTC
Permalink
Hi,

in january a master student is also starting to implement an open source
AES67 client in his thesis under my supervision.
Perhaps there are some topics to share and collaborate.
But some organizational issues need to be solved at the moment.


BR,
Christoph
Post by Happy
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon).
Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus only
using part of the slot). Initially windows reported an error and it did
not work. Went back to Ubuntu 17.10 on the same machine and it worked
fine. (Same result as another person before me). Disabled the internal
NIC and started Windows again. Voila, it worked ! Re-enabled the
on-board NIC and it kept Working in windows. Just for reference.  Don't
have a AVB audio device so cannot really test them. Looking if there is
any AVB test software out there to use these two cards to transmit AVB
based audio from one to the other.
From talking to Focusrite regarding AES67 and the Rednet series and
firmware support, got the following:  "With regards to AES67
compatibility, this is possible for devices using the 'Brooklyn 2' Dante
chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though it's
possible to upgrade to a Brooklyn 2 (this would be chargeable). All of
our devices using Brooklyn 2 modules have AES67 compliance following the
latest firmware update available from RedNet Control"  (Focusrite
Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP  / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully
suppliers will support some kind of new standard in the future for that
as well ( HTML XML, JSON  or other open messaging over IP to configure
the unit). The Rednet3 will keep the routing/configuration after power
cycling thus until then that should be done under Windows.
Looking forward on the progress  of this project !
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But
the developer and ALX Networks could not agree on the license. The
developer wanted to publish it under GPL, which ALX Networks did not
want. So the implementation was dumped. Well, that is the story how I
know it.
The developer was Florian Faber, but he is no member of the jack-devel
or linux-devel list anymore. Perhapes, he might have some useful
insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any
recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.
BR,
CK
On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr
    With an Intel I210 NIC you can already have AVB in combination with
    Jack. But you have to do some coding yourself to fit your purposes..
    I would never recommend buying MOTU.
    BR,
    Ck
        MOTU just released the 828es with AVB and USB standard compliant
        and two ADAT I/O and Web based (not ALSA) mixer. That would be,
        for now, the ultimate (AVB)  interface for Linux,  if it works.
        On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
             That is such good news.  What(low cost)  hardware would
this
             development be used on to support the developers with
             testing/debugging and maybe even development ?
             * MOTU LP32 (Preferred)
             * MiniDSP
        https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
             MOTU's switch uses midDSP switch hardware)
             I hope someday it will be possible to connect 4 or more 8
        channel
             ADAT modules (32 channels) to a PC under Ubuntu via AVB
        with low
             latency. The only option to get this done under Windows
is a
             Focursrite DANTE based Rednet 3 right now because
        Thunderbolt is not
             really available there as well. Plan to get Rednet3,  but
        that does
             not solve the Linux environment which I prefer. Would love
        to be
             able to use the Rednet 3 under Linux but since DANTE is
        proprietary
             , so unlikely.
                [a] Multi (16+) channel low latency audio I/O using ADAT
        audio AD/DA
                [b[ Bitwig  supporting LV2 plugins.
             With those two,  the Linux Audio environment would be
        perfect and
             the world a better place.
             *(Apology for the re-sends and ignore the previous edits.
        Web based
             Gmail is such a annoyance and un-logically structured)*
        _______________________________________________
        Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
    _______________________________________________
    Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Christoph Kuhr
2018-06-24 10:20:33 UTC
Permalink
Hi *,

long time no update...

AES67 for baresip is nearly ready and is now being evaluated by the
master student.

It will be available two months from now, I think.

Did you make some progress?

BR,
Christoph
Post by Happy
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon).
Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus only
using part of the slot). Initially windows reported an error and it did
not work. Went back to Ubuntu 17.10 on the same machine and it worked
fine. (Same result as another person before me). Disabled the internal
NIC and started Windows again. Voila, it worked ! Re-enabled the
on-board NIC and it kept Working in windows. Just for reference.  Don't
have a AVB audio device so cannot really test them. Looking if there is
any AVB test software out there to use these two cards to transmit AVB
based audio from one to the other.
From talking to Focusrite regarding AES67 and the Rednet series and
firmware support, got the following:  "With regards to AES67
compatibility, this is possible for devices using the 'Brooklyn 2' Dante
chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though it's
possible to upgrade to a Brooklyn 2 (this would be chargeable). All of
our devices using Brooklyn 2 modules have AES67 compliance following the
latest firmware update available from RedNet Control"  (Focusrite
Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP  / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully
suppliers will support some kind of new standard in the future for that
as well ( HTML XML, JSON  or other open messaging over IP to configure
the unit). The Rednet3 will keep the routing/configuration after power
cycling thus until then that should be done under Windows.
Looking forward on the progress  of this project !
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But
the developer and ALX Networks could not agree on the license. The
developer wanted to publish it under GPL, which ALX Networks did not
want. So the implementation was dumped. Well, that is the story how I
know it.
The developer was Florian Faber, but he is no member of the jack-devel
or linux-devel list anymore. Perhapes, he might have some useful
insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any
recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.
BR,
CK
On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr
    With an Intel I210 NIC you can already have AVB in combination with
    Jack. But you have to do some coding yourself to fit your purposes..
    I would never recommend buying MOTU.
    BR,
    Ck
        MOTU just released the 828es with AVB and USB standard compliant
        and two ADAT I/O and Web based (not ALSA) mixer. That would be,
        for now, the ultimate (AVB)  interface for Linux,  if it works.
        On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
             That is such good news.  What(low cost)  hardware would
this
             development be used on to support the developers with
             testing/debugging and maybe even development ?
             * MOTU LP32 (Preferred)
             * MiniDSP
        https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
             MOTU's switch uses midDSP switch hardware)
             I hope someday it will be possible to connect 4 or more 8
        channel
             ADAT modules (32 channels) to a PC under Ubuntu via AVB
        with low
             latency. The only option to get this done under Windows
is a
             Focursrite DANTE based Rednet 3 right now because
        Thunderbolt is not
             really available there as well. Plan to get Rednet3,  but
        that does
             not solve the Linux environment which I prefer. Would love
        to be
             able to use the Rednet 3 under Linux but since DANTE is
        proprietary
             , so unlikely.
                [a] Multi (16+) channel low latency audio I/O using ADAT
        audio AD/DA
                [b[ Bitwig  supporting LV2 plugins.
             With those two,  the Linux Audio environment would be
        perfect and
             the world a better place.
             *(Apology for the re-sends and ignore the previous edits.
        Web based
             Gmail is such a annoyance and un-logically structured)*
        _______________________________________________
        Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
    _______________________________________________
    Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Musicmaker
2018-07-09 07:36:19 UTC
Permalink
Sounds great ! I still have two of the I-210 cards installed and they
run fine.  Though for AES67 they are not really necessary. Have not made
much progress on AoIP due to lots of stuff at the office. The Rednet 3
has come down a bit in price after it jacked up to 1500 euro from 999 .
Was worried they  would phase it out. Focusrite confirmed they won't.
Post by Christoph Kuhr
Hi *,
long time no update...
AES67 for baresip is nearly ready and is now being evaluated by the
master student.
It will be available two months from now, I think.
Did you make some progress?
BR,
Christoph
Post by Happy
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon).
Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus
only using part of the slot). Initially windows reported an error and
it did not work. Went back to Ubuntu 17.10 on the same machine and it
worked fine. (Same result as another person before me). Disabled the
internal NIC and started Windows again. Voila, it worked ! Re-enabled
the on-board NIC and it kept Working in windows. Just for reference. 
Don't have a AVB audio device so cannot really test them. Looking if
there is any AVB test software out there to use these two cards to
transmit AVB based audio from one to the other.
 From talking to Focusrite regarding AES67 and the Rednet series and
firmware support, got the following:  "With regards to AES67
compatibility, this is possible for devices using the 'Brooklyn 2'
Dante chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though
it's possible to upgrade to a Brooklyn 2 (this would be chargeable).
All of our devices using Brooklyn 2 modules have AES67 compliance
following the latest firmware update available from RedNet Control" 
(Focusrite Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP  / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully
suppliers will support some kind of new standard in the future for
that as well ( HTML XML, JSON  or other open messaging over IP to
configure the unit). The Rednet3 will keep the routing/configuration
after power cycling thus until then that should be done under Windows.
Looking forward on the progress  of this project !
Post by Christoph Kuhr
A few years back there had been a AES67/Ravenna implementation. But
the developer and ALX Networks could not agree on the license. The
developer wanted to publish it under GPL, which ALX Networks did not
want. So the implementation was dumped. Well, that is the story how
I know it.
The developer was Florian Faber, but he is no member of the
jack-devel or linux-devel list anymore. Perhapes, he might have some
useful insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any
recommendations ?
They are all ok. I have different versions myself: Intel I210, HP
I210TI. But make shure it is no I217, because they have no traffic
shaping queues. Although they suport HW PTP timestamping.
BR,
CK
On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr
    With an Intel I210 NIC you can already have AVB in combination with
    Jack. But you have to do some coding yourself to fit your purposes..
    I would never recommend buying MOTU.
    BR,
    Ck
        MOTU just released the 828es with AVB and USB standard compliant
        and two ADAT I/O and Web based (not ALSA) mixer. That would be,
        for now, the ultimate (AVB)  interface for Linux, if it works.
        On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
             That is such good news.  What(low cost) hardware would
this
             development be used on to support the developers with
             testing/debugging and maybe even development ?
             * MOTU LP32 (Preferred)
             * MiniDSP
https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
             MOTU's switch uses midDSP switch hardware)
             I hope someday it will be possible to connect 4 or more 8
        channel
             ADAT modules (32 channels) to a PC under Ubuntu via AVB
        with low
             latency. The only option to get this done under
Windows is a
             Focursrite DANTE based Rednet 3 right now because
        Thunderbolt is not
             really available there as well. Plan to get Rednet3,  but
        that does
             not solve the Linux environment which I prefer. Would love
        to be
             able to use the Rednet 3 under Linux but since DANTE is
        proprietary
             , so unlikely.
                [a] Multi (16+) channel low latency audio I/O using ADAT
        audio AD/DA
                [b[ Bitwig  supporting LV2 plugins.
             With those two,  the Linux Audio environment would be
        perfect and
             the world a better place.
             *(Apology for the re-sends and ignore the previous edits.
        Web based
             Gmail is such a annoyance and un-logically structured)*
        _______________________________________________
        Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
    _______________________________________________
    Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Philippe BEKAERT
2018-07-09 13:11:53 UTC
Permalink
Hi Christophe and others,


There has been little progress here on AES67 support in jack. We had to give priority to other issues in response to clients requests at azilpix. However, its still on the list. In fact, I'd need only a couple of work days to finish a first sharable version of a AES67 jack client.

I am also interested in evaluating your students work, whenever ready.

Best,

Philippe.

Philippe BEKAERT
Full professor - project leader
Hasselt University - Expertise center for Digital Media
Wetenschapspark 2, 3590 Diepenbeek, Belgium
www.edm.uhasselt.be
Tel: +32 11 268411
Post by Christoph Kuhr
Hi *,
long time no update...
AES67 for baresip is nearly ready and is now being evaluated by the master student.
It will be available two months from now, I think.
Did you make some progress?
BR,
Christoph
Just received two of these (HP) I-210 "PCI 2.1" cards (from Amazon). Installed one of them in and old PC with a PCI-e 2.0 x 4 slot (thus only using part of the slot). Initially windows reported an error and it did not work. Went back to Ubuntu 17.10 on the same machine and it worked fine. (Same result as another person before me). Disabled the internal NIC and started Windows again. Voila, it worked ! Re-enabled the on-board NIC and it kept Working in windows. Just for reference. Don't have a AVB audio device so cannot really test them. Looking if there is any AVB test software out there to use these two cards to transmit AVB based audio from one to the other.
From talking to Focusrite regarding AES67 and the Rednet series and firmware support, got the following: "With regards to AES67 compatibility, this is possible for devices using the 'Brooklyn 2' Dante chipset. RedNet 3s ship with a 'Brooklyn 1' chipset, though it's possible to upgrade to a Brooklyn 2 (this would be chargeable). All of our devices using Brooklyn 2 modules have AES67 compliance following the latest firmware update available from RedNet Control" (Focusrite Rednets use the Bonjour/mDNS protocol for discovery)
In conclusion, the 3 parts needed for full functionality on Linux
[1] Discovery - mDNS should be doable in Linux, right ?
[2] AoIP / clocking - This AES67 project
[3] Control (of the device) - Windows/Mac for the moment. Hopefully suppliers will support some kind of new standard in the future for that as well ( HTML XML, JSON or other open messaging over IP to configure the unit). The Rednet3 will keep the routing/configuration after power cycling thus until then that should be done under Windows.
Looking forward on the progress of this project !
A few years back there had been a AES67/Ravenna implementation. But the developer and ALX Networks could not agree on the license. The developer wanted to publish it under GPL, which ALX Networks did not want. So the implementation was dumped. Well, that is the story how I know it.
The developer was Florian Faber, but he is no member of the jack-devel or linux-devel list anymore. Perhapes, he might have some useful insights, if you manage to find a contact. ;-)
There are some different I210 card versions it seems, any recommendations ?
They are all ok. I have different versions myself: Intel I210, HP I210TI. But make shure it is no I217, because they have no traffic shaping queues. Although they suport HW PTP timestamping.
BR,
CK
With an Intel I210 NIC you can already have AVB in combination with
Jack. But you have to do some coding yourself to fit your purposes..
I would never recommend buying MOTU.
BR,
Ck
MOTU just released the 828es with AVB and USB standard compliant
and two ADAT I/O and Web based (not ALSA) mixer. That would be,
for now, the ultimate (AVB) interface for Linux, if it works.
On Thu, Sep 28, 2017 at 11:31 AM, happy musicmaker
That is such good news. What(low cost) hardware would this
development be used on to support the developers with
testing/debugging and maybe even development ?
* MOTU LP32 (Preferred)
* MiniDSP
https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>
<https://www.minidsp.com/products/network-audio/avb-dg
<https://www.minidsp.com/products/network-audio/avb-dg>> (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8
channel
ADAT modules (32 channels) to a PC under Ubuntu via AVB with low
latency. The only option to get this done under Windows is a
Focursrite DANTE based Rednet 3 right now because
Thunderbolt is not
really available there as well. Plan to get Rednet3, but
that does
not solve the Linux environment which I prefer. Would love to be
able to use the Rednet 3 under Linux but since DANTE is
proprietary
, so unlikely.
[a] Multi (16+) channel low latency audio I/O using ADAT
audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be
perfect and
the world a better place.
*(Apology for the re-sends and ignore the previous edits.
Web based
Gmail is such a annoyance and un-logically structured)*
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
Chris Caudle
2017-09-28 15:41:08 UTC
Permalink
Post by happy musicmaker
MOTU just released the 828es with AVB and USB standard compliant and two
AVB is not compatible with AES67, at least not the current layer 2
implementations. AES67 is layer 3 based, IP transport. AVB
specifications have provision for IP based transport, but as far as I know
there are no AVB implementations which utilize layer 3 transport, only
layer 2. There are enough differences that you could share some (maybe a
lot) of the code between an AES67 implementation and an AVB
implementation, but they would have to be two separate drivers.
--
Chris Caudle
Philippe Bekaert
2017-09-28 17:25:44 UTC
Permalink
As said in my previous message, I do not consider AVB. There are special provisions for AES67 on AVB networks, but it out of my scope.
Best,
Philippe.
Post by Chris Caudle
Post by happy musicmaker
MOTU just released the 828es with AVB and USB standard compliant and two
AVB is not compatible with AES67, at least not the current layer 2
implementations. AES67 is layer 3 based, IP transport. AVB
specifications have provision for IP based transport, but as far as I know
there are no AVB implementations which utilize layer 3 transport, only
layer 2. There are enough differences that you could share some (maybe a
lot) of the code between an AES67 implementation and an AVB
implementation, but they would have to be two separate drivers.
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Philippe Bekaert
2017-09-28 11:36:54 UTC
Permalink
OK … here are my thoughts ...

AES67 is something else than AVB. It’s operating at a higher OSI layer (3&4 instead of 2), and is reported to work also with standard off-the-shelf IT hardware (no special switches needed etc…), though support for some non-consumer features like PTPv2 is needed for high timing precision. But even without such support, timing accuracy in the order of a few audio frames should be achievable on low cost equipment. Not enough of distributed live audio work perhaps, but probably enough for anyone not wanting to buy a somewhat professional network card offering hardware ethernet packet time stamping (and a PTP Hardware Clock).

I understand there have been fierce discussions what way audio over IP would go, either AVB (ethernet layer), or AES67 (essentially RTP, in higher layer). My impression is that AES67 is way better received by industry, and a safer choice to invest time (and money) in, though AVB does have certain technical benefits over AES67 for high-end applications. The AVB group is now working on a broader class of time critical network transport.

AES67 is essentially raw PCM audio over RTP streams, with clock synchronisation using PTPv2. There’s good support for rtp and ptpv2 on linux, available as standard packages from your distro. There’s a unicast and multicast option, both required for full support of AES67, but most users stick to multicast only. Multicast requires an IGMPv2 compliant switch. Most, also cheaper, managed switches support IGMPv2. Streams are described by the internet standard Session Description Protocol (SDP), ascii text files with well documented and easy to parse entries. Manual configuration is always an option (multicast adres, ports, stream format, or better: loading an SDP file). Supporting any discovery methods such as SAP, RTSP, … is recommended. The ST2110 standard sticks with NMOS. I’ll start with the manual configuration. Unicast support requires SIP for connection management. There exist various open source implementations of SIP, but I will start by focussing on multicast support as a first step.

Some aspects of AES67 may be subject to patents (the standard specs document explicitly mentions audinate). I’ll check out what is patented and what we can do without infringing patents or having to pay license fees. (Anyone from audinate on this list??)

AES67 is the greatest common factor in proprietary interfaces including Ravenna, Dante, a.s.o. Ravenna, Dante a.s.o have AES67 compliant profiles. You’ll be able to connect your jackaudio linux box to Ravenna, Dante etc… equipment if you set up that equipment in AES67 compliant mode - pretty standard stuff, as AES67 is actually made to let different such interfaces work together (interoperability). But AES67 is also exactly the audio part of the upcoming SMPTE ST2110 IP broadcast standard.

AES67 requires supporting 1 to 8 channel streams, sent in packets of 1 milisecond (48 samples per channel in one packet at 48KHz), 48KHz, 16 and 24 bits per sample, but I intend to support also other recommended samplerates, bit depths, stream channel counts, and packet times. Note you can always distribute more channels by broadcasting multiple streams. Hundreds of channels are possible over a gigabit ethernet connection. The packet time of 1 milisecond determines latency : count on 3 miliseconds between sending on computer one and receiving on computer 2 when on the same gigabit LAN. Add the latency by your audio interface, which is most probably larger.

My intention is to implement AES67 support as a jack client operating entirely in user space. After all, its essentially a matter of receiving RTP packets from your network interface, ripping out the audio samples and handing them to jack, or the reverse for a sender. For clock synchronisation, you’ll need to set up ptpv2 separately, installing e.g. the ptpd package and configuring it. You need a clock master - your linux box itself, some other computer, or one piece of your AES67 compliant equipment itself will probably do for most purposes.

The alternative is the implement it as a virtual sound card driver, but that seems more involved. If you already have an audio interface (which you need anyways unless you have AES67 speakers or microphones or use other AES67 compliant devices for capturing/reproducing sound), the client approach should do. I guess this will be the most common use case for our community.

My development system has an RME HDSPe AIO card installed. (happy musician: this interface has 8-channel ADAT, along 2 analog balanced audio, AES3 and SPDIF). It works well under linux (ubuntu studio 16.04), though some tools like the hdspemixer have issues (they are not needed - I use it for monitoring only). RME also has a MADI interface in the same product family in case you need.

However, the client I plan to develop will work in principle with just any jack supported audio interface.

Ideally, I should be able to adjust the audio card clock to the system clock or PTPv2 hardware clock on the network interface itself. Instead, I intend to stick with sample rate conversion, to keep audio from the network and in your audio card synchronised, and prevent glitches.

What I do not have at hand right now, is any other AES67 equipment. I’ll start connecting two computers with our own implementation of the standard.

Who has AES67 equipment and would possibly be willing to assist, at least in testing once time is there?
In the mean while, of course, I’m also trying to get hand on AES67 equipment myself too.

Let me know if you have thoughts to share on this.

Best regards,

Philippe.
Chris Caudle
2017-09-28 20:21:32 UTC
Permalink
Post by Philippe Bekaert
Anyone working on AES67 / ST 2110-30 interfacing with jack audio?
Merging Technology is working on an ALSA virtual sound card that
interfaces to a Ravenna device. Should work with generic AES67 devices as
well.

The state of the driver is very strange, the source is marked GPL2 or
later, but it is stored in a git repository with password. So I can give
you the copy of the source I have, but you have to talk to Merging to get
access to the repository.
Additionally there is a user space daemon required to configure the
driver, connect to streams, etc. that is not released. I do not have a
copy of that yet, I am just studying the kernel mode ALSA driver at the
moment, but I do not understand the intentions of Merging Technologies
yet, I think the kernel mode driver will never be accepted upstream if
they have a closed user mode component. Probably the kernel mode is GPL2
just to meet requirements to link with the kernel.

Also the current version of the kernel driver does not compile. There are
a couple of obvious mistakes that I have just not had time to correct and
send back patches yet, but the fact that the mistakes are so obvious does
not give me confidence that Merging is appying much attention to this
driver at the moment.
Post by Philippe Bekaert
though support for some non-consumer features like PTPv2
is needed for high timing precision.
As far as I can tell none of the existing vendors of audio hardware is
using switches with transparent clock support. For lowest latency you
would need a network card with hardware timestamping, but some not very
expensive Intel cards have that, and software timestamping works if you
accept higher latency. Basically just restating what you wrote
previously.
Post by Philippe Bekaert
My impression is that AES67 is way better received by industry
Especially now that Dante has an AES67 compatible mode. MOTU has AVB
pro-sumer style equipment, but for true professional equipment it seems
that most gear uses Dante (which now has an AES67 compatible mode in the
latest firmware versions) or Ravenna (started primarily in broadcast by
now promoted very heavily by Merging for recording use).
Post by Philippe Bekaert
I’ll start with the manual configuration.
I think Ravenna uses SIP, which should be relatively well supported with
libraries developed for telephony and chat use. Maybe a configuration
interface that passes in the required information, and then you can have
separate front ends, one completely manual, one which queries SIP, etc.
Post by Philippe Bekaert
Some aspects of AES67 may be subject to patents (the standard specs
document explicitly mentions audinate).
Ravenna stick to IETF specified protocols and is explicitly patent free.
I am not sure what the Audinate patents cover, but the guys who developed
Ravenna are convinced they do not cover implementations which stick to
using just the IETF protocols plus PTPv2.
Post by Philippe Bekaert
AES67 is the greatest common factor in proprietary interfaces including
Ravenna, Dante, a.s.o. Ravenna, Dante a.s.o have AES67 compliant profiles.
I would not call Ravenna a proprietary interface, since you can download
the description of the protocol with no license, and it explicitly just
groups together existing protocols defined by IEEE and IETF.
Post by Philippe Bekaert
You’ll be able to connect your jackaudio linux box to Ravenna, Dante etc…
equipment if you set up that equipment in AES67 compliant mode
Note that the earlier Dante design used a different clocking and discovery
scheme, only the newest revision has an AES67 compliant mode. And AES67
is basically a subset of Ravenna, so if you have additional options for
buffer size and sample rate beyond the minimum required by AES67 it should
be pretty easy to be fully Ravenna compliant.
Post by Philippe Bekaert
My intention is to implement AES67 support as a jack client operating
entirely in user space.
Another approach might be to use the GPL2 or later implementation of ALSA
virtual sound card and do a reverse engineered user space tool to
configure the ALSA driver. Should be a similar amount of work but then
the driver would work for any ALSA capable software.
Now that I think about it probably would not make much difference, I can't
think of any audio production software on linux which is not jack capable.
Post by Philippe Bekaert
The alternative is the implement it as a virtual sound card driver, but
that seems more involved.
Indeed, but that work is already done. It just needs to be more widely
distributed.
Post by Philippe Bekaert
Ideally, I should be able to adjust the audio card clock to the system
clock or PTPv2 hardware clock on the network interface itself.
I'm not aware of any audio hardware that lets you do that. You could
potentially have a device which locks to the PTP clock and lets you
specify the sample rate for creating a word clock or AES11 clock for
synchronizing other equipment.
Post by Philippe Bekaert
Instead, I intend to stick with sample rate conversion, to keep audio
from the
Post by Philippe Bekaert
network and in your audio card synchronised, and prevent glitches.
I would recommend the zita resampling library. Jackd 1.x family already
incorporates that, jackd v2 family needs to use zita-a2j and zita-j2a
external clients. Those should work unmodified to transfer between a
hardware sound card and the ALSA virtual sound card. Maybe another reason
to re-use the Merging work.
Post by Philippe Bekaert
What I do not have at hand right now, is any other AES67 equipment.
If you have a Windows machine you can use the ALC Windows virtual sound
card if you have a supported Intel NIC with hardware timestamp support, or
you can use the Lawo Windows virtual sound card which supports software
timestamping and will work on any network card. I tried out the demo
version of the Lawo card and was able to transfer audio from one Windows
machine to another (using an external master clock created by transferring
NTP time using linuxptp on a small linux machine).
The demo version of the Lawo software only runs for 15 minutes at a time
and has to be restarted. The paid version costs about 200 dollars/euros.

Cymatic Audio are working on what should be a relatively affordable
Ravenna interface. It was originally said to be available in fall of
2016, but is now almost a year and a half late because of re-design
undertaken after feedback from the first beta users. Now said to be
available "by the end of the year."
https://www.cymaticaudio.com/products/networking-products/unode-m42

The existing Cymatic 24 channel interface was just reduced in price
considerably, it has a Ravenna option card available. More expensive but
available now:
https://www.cymaticaudio.com/products/networking-products/audiolan-option-card

This card I found on eBay is said by the developer to have been checked
out with the Lawo virtual sound card:
http://hasseb.fi/shop2/index.php?route=product/product&product_id=62
That device is pretty limited, it has a single connector which you have to
configure as either input or output, it cannot operate as a full duplex
device.
Only a little over 100 euro, so much less expensive than the Cymatic
device, much less a Merging NDAC or Hapi.
Post by Philippe Bekaert
Who has AES67 equipment and would possibly be willing to assist, at least
in testing once time is there?
I am willing to assist. I do not yet have AES67 equipment, but I am
considering what to get. I may start with that inexpensive Hasseb device
if it appears that the Cymatic 4 channel device will be delayed again.
--
Chris Caudle
Loading...