27 Sep
2017
27 Sep
'17
9:20 a.m.
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
27 Sep
27 Sep
12:37 p.m.
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
On Wed, Sep 27, 2017, at 10:20 AM, Philippe Bekaert wrote:
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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
28 Sep
28 Sep
6:36 a.m.
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.
3:21 p.m.
On Wed, September 27, 2017 9:20 am, Philippe Bekaert wrote:
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.
On Thu, September 28, 2017 6:36 am, Philippe Bekaert wrote:
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.
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).
Ill 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.
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.
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.
Youll 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.
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.
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.
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.
Instead, I intend to stick with sample rate
conversion, to keep audio
from the
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.
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-c…
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.
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
3002
days inactive
3003
days old
jackaudio@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Chris Caudle -
Philippe Bekaert -
Spencer Russell