The lowest cost AVB DAC would probably be this (DAC only, does not include ADC so you cannot record with it):
US$300 for an 8 channel DAC, single ended I/O, no balanced option
Switch chips with AVB support are getting relatively inexpensive, but there doesn’t seem to be much support in end devices (likely because of the software complexity). The 5 port MOTU switch is probably using one of the small Marvell devces, Linksys or Netgear could put one of those devices in a home router, but if they have it does not seem that they have enabled the AVB software support. MiniDSP has a device you can buy for US$120, but it is a bare circuit assembly, no case, so definitely a hobby type of project, not a turn key off the shelf solution.
However, you can use a single AVB device in a point-to-point connection with no switch, so if you have to add in a new Ethernet card anyway, assuming your machine already had an Ethernet or WiFi connection you could just treat your new AVB compatible NIC as a dedicated port. At which point you are back to no better off than using USB except for the much longer distance limit (ca. 100m instead of 10m or less).
"the i210 is a good start, but what it lacks is some way of giving jack or even the local sound card a sync signal "
The clock for jackd would need to be derived from the PTP sync, that is a fundamental point of AVB synchronization. Basically a software clock creating interrupts at the appropriate time instead of relying on interrupts from a hardware sound card. For a local sound card to play back the AVB streams you would need to use zita-a2j and zita-j2a, the equivalents built in to jackd v1, or alsa_in and alsa_out plugins, in other words the same as digital audio has always been, you either synchronize to a common clock or you have to use sample rate conversion as a way to move the audio from one clock domain to another. The AVB interfaces all synchronize to the PTP clock, so having an AVB interface and also trying to use another interface is really the same situation as trying to use a PCI card interface and a USB connected interface together, you either make a clock connection to synchronize or you have to use an SRC adapter.
The biggest advantage for AVB is the automated bandwidth reservation, automatic priority control, etc. that makes sure enough switching bandwidth is available before letting a device join, and making sure that general network traffic does not block the media traffic. With a little bit of knowledge and manual setup of VLAN and service priority you can configure a managed switch to get pretty close to the same performance, which is what AES67 compatible protocols rely on. That doesn’t require specialized switches, just mid-range business class switches for shared network use, or even a pretty low end switch if you are willing to have separate switches for audio use and for the rest of your Internet and general local network traffic. Audinate has an AES67 compatible mode for Dante devices now, SMPTE is standardizing on AES67 audio transport for the new video over IP standard. It seems at least for the pro market that layer 3 transport is going to win out over the layer 2 AVB transport.
Unfortunately AES67 support on Linux isn’t in much better shape than AVB. It potentially could be.
I got access to a virtual ALSA driver for AES67, but the developer wasn’t really keeping up with Linux development, it would not compile on current Linux kernels, a couple of API had changed so it only worked with kernel versions up to several months back. The driver was marked GPL but was not on a public repository. Supposedly it was going to be released publicly at some point, but I have not heard anything more of that. I started working on fixing up the API use so it would work on current 4.14 based kernels, but that is somewhat tedious without a public git server to work from.
Someone else was working on a jackd client to support AES67, but that has been delayed by other paid work that had to be prioritized. I expect that still will happen in a few months.
The hardware interface situation for AES67 compatible devices is not not really any better, only a couple of Ravenna interfaces are available at what I consider to be pretty high prices. I prefer Ravenna because of the completely open specification, but even if you are willing to go with Dante in AES67 mode to avoid the proprietary licensing hassles of original Dante, the available devices are pretty expensive. So not something you would choose over USB for home use.
I really wanted Ethernet connected interfaces to become the new available everywhere kind of interface, but it just doesn’t seem to be happening. For now that is still USB with the limits that go along with that (limited distance, no standard way to synchronize multiple devices except external word clock, problems associated with hub design rather than packet switching, etc.). Maybe it will get there eventually.
If anyone wants to donate a Merging Technologies Hapi interface for me to play with, I will gladly help make it happen faster.