Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 54 of 54

Thread: Ethernet audio library ready to beta test

  1. #51
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    733
    Sounds like nice work.

    IMO, the long term right approach would be an AES67 implementation for the teensy 4.1. Possibly based on the available ESP32 code.

  2. #52
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    169
    yes, AES67 would be nice - but it's a lot of work and there's not much in the public domain (other than the ESP32 code you mentionhttps://github.com/ndac-todoroki/esp32_aes67_sender - and he seems to have abandoned it because the packet rate was unachievable, evern with a processor dedicated to WiFi.). This leaves a lot of the heavy lifting still to be done - e.g. QoS - for a proper AES 67 implementation.

    I'm thinking of aligning with a simpler format in the short term - a protocol called VBAN developed by VB-Audio for their range of (largely free) windows audio programs. https://vb-audio.com/Voicemeeter/vban.htm

    Probably next will be to finish the update of the 8 x 8 channel audio board (a T4 update on Paul's original design). I've got RevB boards sitting on the bench waiting to be loaded and tested for N&D. Rev A proved the design.

    After that, VBAN on the current WIZNET hardware, followed by a port to the T4.1 native ethernet (again - all the bits sitting here waiting for some time to put it all together).

    Finally, something like AES67 to make a nice, compliant overall package!

    Sadly, I'm distracted by other projects at the moment - like work!

    Anyway, keep in touch, because I will get back to this project. It was driven by my band's need for better, personalised, foldback: 8 channel unit plugged into the desk, individual 2 channel units using Paul's SGTL5000 audio boards, transport over ethernet.

  3. #53
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    733
    For the teensy, I think QOS is just a matter of tagging outgoing packets. ??

    PTPv2 (for clock sync) is a big requirement for AES67, but this is hugely beneficial when you are dealing with a variety of audio sources. VBAN uses a non-scalable "receiver needs to infer an exact rate and adjust". But not clear that there is any viable way for a teensy 4 to dynamically adjust its audio clock rate.

  4. #54
    Senior Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    169
    True on both counts.

    With AES 67, there's not much point in the Teensy tagging packets if they are not properly dealt with across the network. For a private "audio only" network, particularly if it has 1GB capable switches, that's not usually a problem, as congestion is unlikely with reasonable audio streams.

    You have noted the transcoding limitation of VBAN, as it's a protocol, not an audio engine. It is common with AES67, where the host also needs to do any transcoding. However you can simply make sure all the endpoints are talking the same bit depth and bitrate for most practical projects. The reason for VBAN: It's very close to my current UDP protocol, so we get significantly increased utility for very little work.

    Building an proper AES67-compliant stack requires a nearly-complete re-work of my code (a new project), and some of the stack's components are simply not there for a Teensy. If someone else creates the components, like PTPv2 clock, (and the Teensy Native Ethernet folks are doing a great job on the network core) I'll hook them in. I agree that an ethernet-transported world clock would be a wonderful thing.

    Another key limitation with my implementation is that it ignores packet loss (out of sequence packets don't happen in most LANs). Fixing dropped packets is a trade-off with latency, as there needs to be sufficient latency in the chain for a dropped packet to be re-inserted without interrupting the audio. This would push out the number of audio buffers required by several times, and with Paul's reasonable choice of 128 sample buffers (2.9mS per buffer), latency grows quicwith additional queue buffers to the point where the set-up becomes unusable for live sound.

    Thanks for the lively discussion, this thread has been quiet for a while - mainly because I've been working on other things.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •