Glensound AoIP44 / Dante Ultimo X4 Chipset

[Nicholas Humfrey]

Hi!

I had been looking for an off-the-shelf / reference hardware implementation of AES67, so that I can attempt to build open source software against it. I bought a Glensound AoIP44, which was very expensive for a personal purchase but was a lot cheaper than an Axia xNode.

Glensound IP products use Audinate Dante - one of the most common implementations of AoIP for professional audio. Although when I received my 2017 edition AoIP44 I was very disappointed to discover than not all Dante implementations support AES67 - they use the proprietary Dante protocol. However after contacting Glensound, they were fantastic and very kindly replaced it with a new 2018 version, which uses a newer version of the Dante Ultimo X4 Chipset.

My observations are:

• When AES67 mode is enabled, it appears that the sample rate is fixed to 48khz and the encoding fixed at PCM24
• It is not possible to enable AES67 mode in Dante Virtual Soundcard
  • I contacted Audinate and they have no plans to add support for it
• SAP Announcements are sent every 30 seconds (too long to wait for in a CLI tool?)
• I have not yet seen an RTCP packets being sent (should be on port 5005)
• AOIP44 appears to be using both PTPv1 and PTPv2
  • PTPv1 might be for Dante Protocol?
  • PTPv2 might be for AES67?
  • MacBook (Dante Virtual Soundcard) only appears to be using PTPv1
• The AOIP44 is making Multicast DNS queries
• It appears to be used for service discovery by Dante Controller and finding devices on the network
• It doesn't appear to be being used for AES67 audio
• It uses the service names netaudio, netaudio-cmc, netaudio-arc, dante-ddm-c

• They don't appear to be registered with IANA

• Disappointingly it only appears to be able to transmit two AES67 multicast flows at a time. It is therefore not possible to create 4x mono AES67 flows.
• I haven't yet worked out how to get it to receive an AES67 flow - it probably needs a SAP announcement that it likes the look of.

Hopefully this is useful information for anyone else looking to working with Dante and writing custom software that talks AES67 with it.

nick.

[BOJIT]

Hi,

I am currently trying to make a simple 'barebones' implementation of an AES67 node, something to use as a reference to build some software.

I was interested in your first suggestion of a Raspberry Pi and a UBlox module as a PTP master. Unfortunately the ethernet chipsets on the Pi aren't particularly suited for PTP, as they don't support hardware timestamping.

However, I have been looking at some STM32 dev boards and some of their cheap (£20) Nucleo dev boards appear to have support for hardware timestamping with PTPv2. 

In particular their F767ZI boards look the perfect fit: https://www.st.com/en/evaluation-tools/nucleo-f767zi.html

I'm quite busy at the moment, but over the summer I am aiming to make a simple PTP grandmaster that runs off one of these dev boards and a GPS module, which can be used for testing purposes.

Also, Ravenna do have a free virtual soundcard for up to 8x8 channels which is fully AES67-compliant, and uses PTPv2. With this it should be possible to make a software-only AES67 stream. As far as I have seen, Audinate's AES67 support is patchy at best.

Thanks for setting up this group, and I'll report back if I get anywhere with this.

Thanks,

James

[Nicholas Humfrey]

Hi James,

Those STM32 boards look interesting - would be a fun project! Are you aware of any Open Source PTP implementations that would run on such a small amount of RAM, or are you planning on implementing PTPv2 yourself?  I wonder what sort of latency/jitter can be achieved without hardware time-stamping? I imagine that the Raspberry Pi using USB for Ethernet isn't going to help latency either.

If doing analogue <-> AoIP, the other hardware requirement is being able to accurately adjust the clock of the audio ADC/DAC converters.

I tried the Ravenna Virtual Sound Card on my Mac, but failed to get it to work - because of annoying security / permission problems.  The proprietary license for the Linux build isn't going to do anything to help adoption :-(

I do wonder if Audinate added AES67 support, just so they can tick a box - rather than actually wanting to participate in an AES67 ecosystem.

nick.

--
You received this message because you are subscribed to the Google Groups "Audio over IP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audio-over-i...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/581225fb-05db-4925-bc0f-49fd69a729df%40googlegroups.com.

[BOJIT]

Hi,

Currently I'm looking at ptpd built on the LwIP stack. There is an excellent paper on the subject here https://arxiv.org/ftp/arxiv/papers/1806/1806.10036.pdf, where they have managed to implement a lightweight ptp daemon onto an STM32F4 series chip, so I think it should be possible with the small amount of RAM available. 

For analogue audio implementation I picked up a couple of the Behringer ADA8000 units. These are ADAT in/out, and they can be clocked externally through the ADAT input, which means I should be able to get 8 channels in/out without having to mess about with any analogue circuit design. You can also pick them up for about £50 used on EBay, so they are good for experimenting with.

The long-term aim after getting some sort of stable PTP synchronisation is to make an open 8 in, 8 out AES67 node. That will most likely need some sort of FPGA implementation, but ADAT is relatively straightforward to implement on an FPGA, see this article: https://ackspace.nl/wiki/ADAT_project

Currently the overall structure I am planning is as follows:

As for the importance of hardware time-stamping, I suspect that there is a bit more leniency in networked audio. After all, plenty of performers use Dante Virtual Soundcard on a Mac through an ethernet adapter, which I doubt has PTP timestamping in hardware. It is also recommended to use 'PTP-aware' switches that compensate for the time spent in the switch, but they are an order of magnitude more expensive than regular gigabit switches. I am hoping that AES67 can be implemented somewhat reliably without using these switches, as the added cost makes the whole 'networked audio' appeal less attractive IMO.

I'm hoping it's possible to still get good performance without absolutely perfect network conditions, as I think the hardware needs to be much more affordable before we see a lot more open-source software tools. I imagine that the really high-end PTP hardware is more intended for stock exchanges and research (in fact the PTP node discussed in the paper linked at the top is for use in the ITER tokamak).

The proprietary Linux licence is a shame, but at least Ravenna have published a lot of helpful resources that may go some way towards helping build an open-source alternative :)

James

To unsubscribe from this group and stop receiving emails from it, send an email to audio-...@googlegroups.com.

[Nicholas Humfrey]

Hi!

That sounds like a very impressive project!

If you get the PTP Grand Master working, I would love to try and build a copy of it.

I was trying to install ptpd 2.3.1 on my Mac today and saw the following notice:

"As of 2.3.1, PTPd still does not support hardware timestamping."

Do let us know how you get on...

nick.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-over-i...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/5352ee48-7369-4ae5-a510-2bfdbcc3e533%40googlegroups.com.

[Gene Gerhiser]

I have been running Ravenna/AES67 nodes on a Cisco SG300.  Most of the small demos you see at Trade shows like NAB and AES, will use these small switches and I believe Merging Technologies gives you a configuration for a cheap Dell or D-link switch.  The PTP accuracy of the switch is not as important in a small scale environment as it is in our large corporate environment where you PTP messages running across the network may take several hops.  

Merging's VAD (virtual sound card) works well on MAC but I had great diffuculty in using it on a PC.  Also, in order for that driver to work, it needs to "handshake" with a Merging device on the network.  So it will not work by itself.

 Lawo's R3LAY will work stand a lone.  And you can download a demo of the software that works well enough for testing Streams or PTP clocks on the network.  

Ravenna Virtual sound card driver had issues early on with syncing to PTP on the network unless you used a particular Intel chipset, and had a PTP clock that ran in "two-step" mode.  Our PTP grandmaster clock is only set up for one step mode because it timestamps the packets on the egress of the hardware NIC port.  Thus I was not able to get it to work with RVSC several years ago.  That being said the Lawo R3LAY does not require a particular NIC chipset in order to work properly as it takes the PTP coming in from the network and "syncs" its clock with windows High Performance Event Timing if I remember correctly.  

Thanks,

Gene