OpenAvnu is the open building blocks of AVB and TSN, without the product

Components, not a system

The OpenAvnu project is sponsored by the Avnu Alliance, and the intent is to provide components for building AVB and TSN systems. The repository contains primarily network building block components: drivers, libraries, example applications and daemon source code, required to build an AVB or TSN system.

Then comes the sentence that sets expectations better than any marketing would. This repository does not include all components required to build a full production AVB/TSN system, for example a turnkey solution to stream stored or live audio or video content.

What it does provide are some simple example applications which illustrate the flow. The distinction is between the network and the media, and it is a real architectural boundary rather than a gap in the work. A professional audio and video system requires a full media stack, including audio and video inputs and outputs, media processing elements, and various graphical user interfaces, and the README notes that various companies provide such integrated solutions.

So the audience is someone building a device or a system that needs to speak AVB or TSN correctly, and who is assembling the rest themselves. That is a narrower audience than the acronym suggests and a perfectly good one.

The plan for the project is also stated: it is planned to eventually include the various packet encapsulation types, protocol discovery daemons, libraries to convert media clocks to AVB clocks and vice versa, and drivers. The list reads as a roadmap rather than a completion report, which matches the fact that the repository has no published releases and the last push was on 2026-09-09.

The code is C, and the project website is at avnu.github.io/OpenAvnu.

Why Intel published it, and who contributes

The Background section explains the origin and the motivation, and it is a policy statement as much as a history.

Intel created the OpenAvnu repository to encourage collaborative source code development for AVB and TSN technology. The repository was created by the Intel LAN Access Division, and by publishing the source code the intent is to encourage standardization, stability and inter-operability between multiple vendors. The repository is open for contributions from other vendors.

That is the origin story with a technical purpose. Audio Video Bridging was a set of standards for deterministic networked audio, and Time Sensitive Networking is the broader family of mechanisms for scheduled traffic. Both need silicon from several vendors, and both need the implementations to behave identically across them, or an AVB speaker from one manufacturer will not interoperate with a switch from another.

Publishing the reference implementation is the way to make that happen, and the framing of interoperability between multiple vendors is the reason the acceptance rules in the licensing section are as strict as they are.

The project also has a development mailing list, at lists.sourceforge.net, and the repository carries a `documents/` directory for specifications and background reading, `thirdparty/` for vendored code, and a `test/` directory.

The one branch worth knowing about is the Apple Vendor PTP profile. Support for it is on the `feature-aptp-experimental` branch, and those changes allow interaction with Apple proprietary PTP clocks. The README says the implementation has been tested with the Apple AirPlay SDK on a Raspberry Pi 3 running within a group of devices playing the same music stream, which is a precise and useful statement of scope: experimental, tested against one vendor's SDK, on one class of device.

Mixed licensing, and strict rules for outside contributions

The licensing section is the most careful part of the README, and it exists because the project mixes licences on purpose.

To the extent possible, content is licensed under BSD licensing terms. Linux kernel mode components are provided under a GPLv2 licence. The specific licence information is included in the various directories to eliminate confusion, and the project asks you to review the `LICENSE` file included in the head of the various subdirectories for details.

So a repository-wide statement of the licence does not exist, and the per-directory files are the ones that matter. That is a deliberate choice, because a kernel module and a userspace daemon can carry different terms without any conflict, and a single top-level licence would have been wrong for one of them.

The rules for third party submissions explain why the split exists. Third party submissions are welcomed, and the intent for third party content contributions is to enable derivative products with minimal licensing entanglements. In practice this means two things would be enforced: an original-source attestation for any contributed content, and rejecting patches with GPL content into existing BSD licensed components.

The second rule is the one to understand. Because GPL content cannot be merged into a BSD component without changing that component's terms, a patch that imports GPL code into a BSD directory would either relicence the directory or break the separation the project depends on. So it is rejected at the door rather than adjudicated later.

Third party copyrights can be included provided they do not narrow the licensing terms of an existing component. That is a one-way rule as well: a contributor cannot add a term that restricts what others can do with the component they contributed to.

Building it on Debian and with CMake

After checking out the repository, the submodules should be configured, and the commands are:

    git submodule init
    git submodule update

That step is easy to skip and produces confusing failures, because the parts you build live in submodules.

For Debian, the build dependencies and the build are:

sudo apt install libpci-dev libpcap-dev libsndfile-dev libjack-dev
make all
make -C lib/igb_avb all

The dependency list tells you what the code talks to. `libpci-dev` is for PCI device access, which is how the IGB driver finds the network hardware, `libpcap-dev` is for packet capture, `libsndfile-dev` is for audio file handling, and `libjack-dev` is for the JACK audio system, which the audio examples use.

The second make line is separate because the IGB library is built as its own component under `lib/igb_avb`, which is the user space library for the Intel Gigabit Ethernet driver that AVB uses.

CMake is offered as an alternative for a subset of the tree. The README says cmake build files are currently available to build mrpd in Windows and linux and CppUTest unit tests for mrpd, and recommends an out-of-tree directory for the generated makefiles or MSVC project files:

    mkdir tmp
    cd tmp
    cmake .. -G "Unix Makefiles"
    make

which builds in OpenAvnu/tmp. The out-of-tree recommendation is standard CMake practice, and here it matters more than usual because the source tree contains generated content and submodules.

The Makefile target list is a map of the system

The root Makefile prints a help target that doubles as an index of the whole project, and reading it tells you what the system is made of.

	@echo 'Possible targets:'
	@echo ''
	@echo '  atl_lib	       - atl library'
	@echo '  lib               - igb library'
	@echo ''
	@echo '  daemons_all       - build all daemons (mrpd maap shaper)'
	@echo '  mrpd              - mrpd daemon'
	@echo '  maap              - maap daemon'
	@echo '  shaper            - shaper daemon for linux'
	@echo ''
	@echo '  avtp_pipeline     - AVTP pipeline'
	@echo '  avtp_pipeline_doc - AVTP pipeline doc'
	@echo '  avtp_avdecc       - AVTP avdecc'
	@echo '  avtp_avdecc_doc   - AVTP avdecc doc'
	@echo ''
	@echo '  examples_all      - build all examples (simple_talker simple_listener mrp_client live_stream jackd-talker jackd-listener)'

The three daemons are the core of the runtime. `mrpd` is the MRP daemon, the multicast registration protocol that lets talkers announce streams and listeners find them. `maap` is the MAAP daemon. The `shaper` is the traffic shaper for Linux, which is the piece that enforces the reserved slot behaviour that makes the network deterministic.

Two libraries sit under the daemons: the ATL library, and the IGB library, which is the user space side of the kernel driver that gives the interface its time-aware capabilities.

The AVTP targets are the pipeline itself and the AVDECC management layer, each with a documentation target alongside, which tells you the project treats the generated documentation as a build output rather than something written by hand.

The examples list names the roles in a streaming system: a talker and a listener, a client for the MRP protocol, a live stream, and JACK talker and listener applications for audio.

The cleaning targets follow the same convention, with a `_clean` suffix on each and a summary `clean` target, and the help text spells out the rule that all of the above with the `_clean` string appended cleans the respective build directory.

The example tree, the run scripts and the neighbouring projects

The repository root carries a set of shell scripts that run the pieces, and their names are a good map of what you would start. There is `run_gptp.sh` for the generalised precision time protocol, `run_maap.sh` for the control plane, `run_srp.sh` for the stream reservation protocol, `run_igb.sh` for the driver, `run_shaper.sh` for the shaper, `run_atl.sh` for the transport layer, `run_avtp_pipeline.sh` for the pipeline, `run_daemons.sh` to start the daemons together, and the talker and listener examples `run_simple_talker.sh` and `run_echo_listener.sh`. The `stop_` variants exist for the daemons and the pipeline.

So a typical session is: start the driver, start the daemons, start the pipeline, then run a talker and a listener.

The examples directory is broader still, with `alsa_timed_audio` for audio through the ALSA interface, `atl_simple_talker`, `common`, `gstreamer-avb-plugins`, `jackd-listener` and `jackd-talker` for audio through JACK, `live_stream`, `mrp_client`, `osx` for the Apple platform, `send_packet_precisely` for the timing test, `simple_listener`, `simple_rx` and `simple_talker`.

The README also points at related open source projects, and the reason is instructive. AVDECC is a management layer, similar to SNMP MIB formats, which enables remote devices to detect, enumerate and configure AVB and TSN-related devices based on their standardized management properties. Jeff Koftinoff maintains a repository of AVDECC example open source code, and AudioScience has created a 1722.1 C++ controller library which builds on it. XMOS is a semiconductor company providing a reference design for AVB and TSN endpoints in pro audio and automotive, and the endpoint source code is open and available on GitHub.

That list shows the division of labour in the ecosystem. OpenAvnu provides the network side and the daemons, the AVDECC projects provide the management and control library, and the silicon vendors provide endpoints.

Editorial conclusion

Adopt OpenAvnu if you are building an AVB or TSN system and need the network layer, the daemons and the reference code rather than a vendor appliance, and if you can assemble the media side yourself. Do not adopt it expecting a working product, since the README says plainly that it does not include what a production system needs. Verify first that the submodules are initialised with `git submodule init` and `git submodule update` before you build, that your kernel has the IGB driver the library targets, that you read the `LICENSE` file in each subdirectory rather than assuming one licence applies, and that the version you take is the state of the `master` branch, since the repository publishes no releases and the last push was on 2026-09-09.

Frequently asked questions

Official sources

1. Avnu/OpenAvnu on GitHub
2. Issues
3. README