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

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

Re: AES67 / SMPTE ST 2110-30

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


On Sat, Oct 21, 2017 at 10:13 PM, Chris Caudle <[hidden email]> wrote:
On Mon, October 2, 2017 5:12 am, Philippe Bekaert wrote:
> 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


_______________________________________________
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
On Sun, October 22, 2017 10:31 pm, happy musicmaker wrote:
> 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.

> 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


_______________________________________________
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 Chris Caudle
On Mon, October 23, 2017 4:32 am, Philippe Bekaert wrote:
> 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


_______________________________________________
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
On Mon, October 23, 2017 11:53 am, Philippe Bekaert wrote:
> 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


_______________________________________________
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

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 !


On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)
>
> 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

Christoph Kuhr
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

On 12/20/2017 07:45 AM, Happy wrote:

>
> 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 !
>
>
> On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)
>>
>> 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

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



On 12/20/2017 07:45 AM, Happy wrote:

>
> 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 !
>
>
> On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)
>>
>> 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

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



Am 20. Dezember 2017 10:37:46 MEZ schrieb Christoph Kuhr <[hidden email]>:
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

On 12/20/2017 07:45 AM, Happy wrote:

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 !


On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)

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>





--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
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

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

Best,

Philippe.

Philippe BEKAERT
Hoogleraar - projectleider
Universiteit Hasselt - Expertisecentrum voor Digitale Media
Wetenschapspark 2, 3590 Diepenbeek, Belgie
+32 11 268411





On 16 Jan 2018, at 10:50, zmlopez <[hidden email]> wrote:

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
_______________________________________________
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 zmlopez
On Tue, January 16, 2018 3:50 am, zmlopez wrote:
> 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




_______________________________________________
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

zmlopez
In reply to this post by Philippe Bekaert
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
_______________________________________________
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

zmlopez
Reply | Threaded
Open this post in threaded view
|

Re: AES67 / SMPTE ST 2110-30

Chris Caudle
On Wed, January 17, 2018 7:56 am, zmlopez wrote:
> More links about ptp support in gstreamer:

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




_______________________________________________
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

zmlopez
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
_______________________________________________
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
In reply to this post by Happy
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


On 12/20/2017 07:45 AM, Happy wrote:

>
> 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 !
>
>
> On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)
>>
>> 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

Happy

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.


On 6/24/2018 6:20 PM, Christoph Kuhr wrote:

> 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
>
>
> On 12/20/2017 07:45 AM, Happy wrote:
>>
>> 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 !
>>
>>
>> On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)
>>>
>>> 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
In reply to this post by Christoph Kuhr
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
Tel: +32 11 268411





On 24 Jun 2018, at 12:20, Christoph Kuhr <[hidden email]> wrote:

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


On 12/20/2017 07:45 AM, Happy wrote:
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 !
On 10/1/2017 4:32 PM, Christoph Kuhr 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. ;-)

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] <[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] <[hidden email]>
        <[hidden email]
        <[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]
        <[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
12