[Jack-Devel] AES67 / SMPTE ST 2110-30

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] AES67 / SMPTE ST 2110-30

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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

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

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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
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 <[hidden email]> wrote:
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 1:37 AM, Spencer Russell <[hidden email]> wrote:
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: <a href="tel:+32%2011%2026%2084%2011" value="+3211268411" target="_blank">+32 11 268411
> www.edm.uhasselt.be
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
In reply to this post by Spencer Russell
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)


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
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 <[hidden email]> wrote:
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)



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

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..


BTW:
I would never recommend buying MOTU.


BR,
Ck


On 09/28/2017 08:33 AM, happy musicmaker wrote:

> 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
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     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.
>
>     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)*
>
>
>
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Philippe Bekaert
In reply to this post by Spencer Russell
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.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Chris Caudle
In reply to this post by Happy
On Thu, September 28, 2017 1:33 am, happy musicmaker wrote:
> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Philippe Bekaert
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.

On 28 Sep 2017, at 17:41, Chris Caudle <[hidden email]> wrote:

> On Thu, September 28, 2017 1:33 am, happy musicmaker wrote:
>> 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Chris Caudle
In reply to this post by Philippe Bekaert
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).

> 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.

> 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.

> 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.

> 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-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.

> 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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
In reply to this post by Christoph Kuhr
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


On Thu, Sep 28, 2017 at 6:11 PM, Christoph Kuhr <[hidden email]> wrote:
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


On 09/28/2017 08:33 AM, happy musicmaker wrote:
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 <[hidden email] <mailto:[hidden email]>> wrote:

    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.

    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)*




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

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. ;-)

On 09/30/2017 06:12 AM, happy musicmaker wrote:
> 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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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
>
>
>     On 09/28/2017 08:33 AM, happy musicmaker wrote:
>
>         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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>              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.
>
>              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)*
>
>
>
>
>         _______________________________________________
>         Jack-Devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>         <http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
>
>
>     _______________________________________________
>     Jack-Devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>     <http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
>
>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

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.



On 01 Oct 2017, at 10:32, Christoph Kuhr <[hidden email]> wrote:

> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Wargreen
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



On 02/10/2017 12:12, Philippe Bekaert wrote:

> 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.
>
>
>
> On 01 Oct 2017, at 10:32, Christoph Kuhr <[hidden email]> wrote:
>
>> 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
In reply to this post by Philippe Bekaert
I am considering to get a pair of these. Intel Ethernet Server Adapter I210T1, single port PCI-e (with 802.1qav support).

Inline image 1

On Mon, Oct 2, 2017 at 6:12 PM, Philippe Bekaert <[hidden email]> wrote:
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.



On 01 Oct 2017, at 10:32, Christoph Kuhr <[hidden email]> wrote:

> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Happy
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 
So if it ONLY supports PCI 2.1 ... (?) Would the card work on 2.0 and 3.0 ?



On Tue, Oct 3, 2017 at 2:56 PM, happy musicmaker <[hidden email]> wrote:
I am considering to get a pair of these. Intel Ethernet Server Adapter I210T1, single port PCI-e (with 802.1qav support).

Inline image 1

On Mon, Oct 2, 2017 at 6:12 PM, Philippe Bekaert <[hidden email]> wrote:
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.



On 01 Oct 2017, at 10:32, Christoph Kuhr <[hidden email]> wrote:

> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Ralf Mardorf
On Tue, 3 Oct 2017 15:19:07 +0800, happy musicmaker wrote:

>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.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Chris Caudle
In reply to this post by Happy
On Tue, October 3, 2017 2:19 am, happy musicmaker wrote:
> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Philippe Bekaert
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.

On 03 Oct 2017, at 16:18, Chris Caudle <[hidden email]> wrote:

> On Tue, October 3, 2017 2:19 am, happy musicmaker wrote:
>> 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org