IEEE 1588 (PTP) synchroniazable ethernet to I2S/TDM 8 channel DAC bridge - Page 1
Forum section: electronics / general

author: knicklicht
author_rank: Newbie
timestamp: November 25, 2022, 05:46:47 pm
content: Hello all,completely new here but I think this might be the right place to ask my questions.I want to build a large set of speakers that all need to be able to play audio synchronously but possibly different audio streams. The speakers are divided into sets of 8 which are in close proximity (all drivers are in one enclosure/cabinet). The groups are further apart but no more than 20 meters. All speakers receive the audio signal from a central PC. I am trying to come up with a cheap and modular way of connecting all these speakers and the PC. One design which I am trying to evaluate consists of an Ethernet based system. The central PC is equipped with a hardware PTP enabled gigabit NIC. The audio signal is streamed to a set of MCUs which each bridge the audio stream to 8 channel I2S/TCM and finally to DACs.The viability of this design depends on the availability of an MCU that fulfills all of these requirements. I have been looking around and it seems that not many MCUs support PTP or for which a library is publicly available. I have found the ST32F429ZI. However, there is no information on how to use I2S/TDM with it. The ESP32-C3 support the TDM side of things but I cant find anything on PTP. How would I refine my search method to find what I am looking for?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 25, 2022, 06:35:45 pm
content: You probably mean I2S, not I2C?

author: knicklicht
author_rank: Newbie
timestamp: November 25, 2022, 07:13:23 pm
content: Yes, thanks. Corrected.

author: nctnico
author_rank: Super Contributor
timestamp: November 25, 2022, 08:37:21 pm
content: You'd need to run a PTP protocol stack for which there are open source versions available but likely you'll need to add low-level drivers for your microcontroller. And you'll also need some ways to steer the oscillator of the microcontroller to make the frequency adjustments.In the end having 1ms accuracy should be good enough; NTP works just fine at that level for a local network and is massively simpler to implement. You'd still need an oscillator that can be adjusted somewhat but no hardware timestamping support. With a large number of speakers, you'll likely run into issues where listeners hear multiple speakers at different distances. You may want to include the ability to have adjustable delays.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 26, 2022, 03:15:57 am
content: This is a much harder challenge than it looks."Time-aligning" the sample stream between nodes is only half of the job.The other problem, which is significantly more difficult, is to deal with sample clocks that are all different. Basically each DAC node will have its own sample clock, unless you can distribute a master clock, which is not possible using only Ethernet. To make up for that, there are essentially two methods: either adjust the sample clock on each node (assuming you can fine tune the frequency, which is not necessarily possible on typical MCUs), or resample on the fly (takes some DSP resources.) Either way, you'll need to estimate the frequency error for each node compared to one reference node, which can also be done using PTP. The whole thing is non-trivial and I don't know of any easy, ready to use piece of code for this.Just as a gentle warning, it's much harder than it sounds (no pun intended).

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 26, 2022, 05:28:03 am
content: Hmm.. 8×48000×24 = 9,216,000 or 10 Mbit/s per cabinet at 24 bit 48 kHz sample rate.Easily doable by good ol' TOTX141/TORX141 optical TOSLINK transceiver modules (15 Mbit/s), and 20m would work with good quality plastic cables.Use a pair of cables for an unidirectional SPI link per cabinet. Say, use 32 bits for each 24 bit sample; perhaps using the four bits for channel sync and keeping the bit ratio closer to 50% – even just using one bit to indicate when to XOR the data word with a 0b010101..0101 mask. Being optical, there would be no risk of ground loops or picking up EM noise. (S/PDIF and AES3 use a single cable, and a clock recovery scheme, which has some jitter.)One could use the 12,288,000 Hz (8×32×48000) as the master clock directly, one cable being basically just the clock, and eliminate jitter and all clock issues completely. It also happens to be a 256f master clock for any 48kHz DAC (if using I²S stuff). If both ends are SPI slaves, and you generate a continuous 12.288MHz clock on the clock cables, you could probably use it as the master clock for a microcontroller on the receiving end, with cycle-perfect time sync.Pity TOSLINK hardware is so hard/expensive to find nowadays.There was S/PDIF over 75Ω coaxial cable with 1 Vpp signaling, but I'm just a hobbyist who prefers the optical stuff, and don't know how one would go about implementing the transmitters and receivers for that.

author: knicklicht
author_rank: Newbie
timestamp: November 26, 2022, 11:43:03 am
content: Thanks for the feedback.@nctnico: I don't think that NTP will be sufficient. 1ms accuracy is already pretty much the best case for NTP even in small LANs in practice. 1ms is also the mean with a standard deviation of a couple of ms. However, the human ear starts hearing timing difference at around a few ms but 1ms is also not the accuracy that I need in practice (see below).@SiliconWizard: Interesting point. Up until now I thought that for audio applications the difference in sample clock frequencies would not be significant. Just so that I understand you correctly: Each node with a DAC uses its own oscillator from which the sampling frequency is derived, e.g. "48kHz". However, this frequency is not constant across nodes. One might be 48.1kHz and another 47.9kHz compared to a reference. Can I estimate the typical frequency deviation? This also gives me a tight constraint on the PTP accuracy which I need to achieve as I need to be able to detect this deviation. E.g. 1Hz accuracy at 48kHz would require ~20us accuracy (1/48kHz). From the papers that I read this is viable using PTP even without hardware timestamping. I am not to worried about the work needed to resample as this can be done in C which is where I feel comfortable. Correct me if I am wrong but resampling a kHz signal on a MHz MCU should not take to much optimization. Because I have not had to choose a MCU with such specific requirements until now it seems like I am approaching the the search wrong I need to figure out which parts are hardware dependent and which parts can be handled by software while using existing open source solutions.@Nominal Animal: I thought about distributing the signals through other means as well e.g. some form of (differential) PWM. I like the Toslink approach but it seems to me that I would have a huge cable mess on my hands. Assuming I have 18 cabinet that would mean I need 36 Toslink cables. However, this is not my biggest issue with this approach. I'd still need to get the signal from my PC to some board with 36 Toslink connectors on it. I could use a fast serial connection such as USB or I could use Ethernet. I have a Zedboard FPGA here but I am trying to reduce the cost for the whole system and I would like to keep it as reproducible as possible. With the current chip shortage I think that using common MCUs and readily available networking/interconnect technologies will make the whole thing easier to reproduce. I am basically trying to figure out which "PC to speaker" bridge technology makes the most sense. I know that there is a lot of commercial stuff tackling exactly this problem, e.g. AVB, Dante, etc., but it seems to me that there is pretty much nothing in the OSS space.

author: nctnico
author_rank: Super Contributor
timestamp: November 26, 2022, 01:31:25 pm
content: If you are going to do time & frequency synchronisation, it is only logical to apply the adjustments to the oscillator that drives the DACs as well. If you use a tuneable TCXO (costs around 15 euro each) you should be able to pull it off. Also note that PTP without hardware timestamping is basically NTP. Both estimate the network delay + clock offset and adjust the clock accordingly. The only functional difference (without hardware timestamping) is that NTP typically uses a much lower packet rate (like once per couple of minutes or even once per day) where PTP uses higher packet rates (at least several per second). So if you implement NTP with a higher rate (say 4 to 16 packets per second) and use a slow PI control loop, you can steer the oscillators on each board to be in sync without needing to implement PTP which is rather complex (I have been dealing with PTP protocol implementation for quite a few years already).

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 26, 2022, 06:22:22 pm
content: Quote from: knicklicht on November 26, 2022, 11:43:03 amTrue. They are easily sleeved or even taped together – being plastic throughout – so it's mostly just a connector issue, but still.How about a mixed approach: use plain ol' UDP for data –– over Ethernet, or WiFi using something like ESP32 ––, but a common distributed clock to sync to? For example using one of the free wireless bands, sending a clock bitstream, perhaps even just a 96 kbits/s 0b10 pattern per sample – i.e., one pulse per sample?Hmm.. too many moving parts for my taste.How about using Cat5e SF/UTP cables (four twisted pairs in a common foil shield) in a star configuration, using one twisted pair for clock, the other for data (so still unidirectional SPI), with NRZ and say ±12V drivers (and non-magjack RJ45 connectors); and magjacks on the receiving end? The overall data rate from the host PC to 18 cabinets at 48kHz 24bit 8-channels/cabinet is 18×48000×8×24 bits per second = 165,888,000 bits/sec, or 20,736,000 bytes per sec. Again, using 12,288,000 Hz clock rate, for nominally 32 bits per sample. You could even use a third pair for a /SS signal, enabled for 24 to 31 clocks out of every 32, to ensure exact sync.Atrivial example programon Teensy 4.0 can achieve 200+ Mbits/s, or 25.7 Mbytes/sec, in one direction (high-speed USB 2.0, 480 Mbit/s). Having 18 SPI in parallel, using the same master clock at 12.288 MHz, is a bit tricky, though. Moreso, because although the per-cabinet bandwidth needed is just 9.216 Mbits/s, is not really achievable with full-speed 12 Mbit/s USBs most microcontrollers have, in my experience (i.e., 18 separate full-speed USB MCUs would not work, due to USB overheads et cetera, even if it might look like it should, because 9.216 < 12). Isochronous USB transfers? Perhaps, but it is very, very close, especially considering using 18 of them in parallel.If you had a small FPGA (say iCE40) that could interface to a Teensy Micromod, you could use a parallel 8-bit 8080-style bus with separate clock/write strobe. One sample to 8 channels in 18 cabinets is 24×8×18/8=432 bytes, so the minimum transfer rate would be 20.736 Mbytes/sec. If one used exactly twice the per-cabinet SPI clock, 24,576,000 Hz, say from a crystal, halving it for the SPI buses, then the SPI-driving FPGA simplifies to a multiplexer with 32-bit parallel-to-serial shift registers and counters. Say 64 to 128 bits per SPI bus, to allow for jitter in the DMA setup (as the bus duty cycle is 432/512≃85%). The FPGA would create the 18 unidirectional SPI channels and 24-31 out of 32 cycles /SS signals, and you'd use a separate power board for the ±12V signal drivers and cable connectors. Note that that would be 18 data output pins, 1 /SS pin (shared across cabinets), 1 clock pin (shared across cabinets), 8 data input pins and and its read/write strobe pin and a select pin, for around 30 I/O pins.For experimentation, taking anOlimex iCE40HX1K-EVB, and replacing the 100 MHz oscillator with a 98.304 MHz one (8× SPI bus clock, 4× the parallel Teensy bus clock, bus master in all cases), to find out if this is actually doable, would be interesting, and not too expensive. While the FPGA would need to generate all 18 SPI data outputs, only one driver-cable-receiver would be needed for testing.This would be my DIY approach, anyway. But I'm just a hobbyist (who obviously likes his Teensy microcontrollers, interfacing them to sensors and stuff), and more of a software than hardware person. Hopefully my musings above are at least amusing, if not informative/useful!

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 26, 2022, 07:00:04 pm
content: Quote from: knicklicht on November 26, 2022, 11:43:03 amIf the oscillators are crystal-based, you're probably going to have a few tens of ppm of difference between all clocks. For the same sampled data (not resampled), you're not likely to hear the difference if listened to separately. If played at the same time, and say the sampled data contains the same base fundamental(s), you may get an annoying low-frequency beat.But the really problematic point is not this. It's the fact that since the frequencies are all slightly different, over time, the number of samples that each node "consumes" in a given time frame is different - so you'll quickly get underruns/overruns, which will create "pops" that are unacceptable.Quote from: knicklicht on November 26, 2022, 11:43:03 amYou got that right. Each oscillator has its own frequency. As said above, the typical difference will be in the order of a few tens of ppm typically for regular crystal-based oscillators. With decent TCXOs (nothing ultra fancy), you may get this down to a few ppm.Quote from: knicklicht on November 26, 2022, 11:43:03 amYes there's a few techniques for this, but the PTP protocol itself should help with that. The idea is that making clever use of timestamps, you can estimate the frequency ratio between each node and a reference node. You won't work at the sample level, but over blocks of N samples.Quote from: knicklicht on November 26, 2022, 11:43:03 amNot necessarily, and that's the "beauty" of PTP.Quote from: knicklicht on November 26, 2022, 11:43:03 amDepends on the kind of resampling you will use. Could be from very simple (linear interpolation) to very advanced.As you may guess, the closer the clock frequencies for all nodes and the simpler the resampling you can use. I have worked on something like this a while ago (not via Ethernet though, but the idea was the same) and estimated the SNR for various resampling methods as a function of the frequency difference in ppm. I'd have to take a look back at it, but linear interpolation may be appropriate for 16-bit audio and reasonable crystal-based oscillators. You could use TCXOs for each node (only a couple bucks) to get it within 10-20 ppm or so and get away with linear interpolation. Very not processing intensive.Otherwise, one all-around resampling method that works well enough (much better than linear) is cubic interpolation (based on Catmull-Rom splines.) More processing intensive of course, but still reasonably simple compared to the fancier resampling techniques.

author: dmills
author_rank: Super Contributor
timestamp: November 26, 2022, 07:38:33 pm
content: What you are describing is AES67 (or SMPTE 2110-30) and is quite doable.For a receiver you need two things from the PTP, firstly to lock up a software clock so that the gross audio synchronisation (as in packet buffering) works properly for all nodes, this is something that can be done in software fairly trivially.Secondly, you need to lock a 11.288/24.476/59152 or whatever MCLK to the PTP time so that all the converters on the network run at the same speed and thus consume data at exactly the same aggregate rate as it is produced.Many PTP capable ethernet PHYs or MACs are capable of outputting a clock locked to the PTP time, at some MHz rate which you can use to derive this required audio clock.

author: nctnico
author_rank: Super Contributor
timestamp: November 26, 2022, 08:26:18 pm
content: Quote from: dmills on November 26, 2022, 07:38:33 pmThat is called Sync-E. That is only usefull IF the clock that feeds the MAC / PHY at the sending end is also synchronised to a master clock. But you'll only get frequency transfer that way. You'll still need PTP to do time transfer.

author: dmills
author_rank: Super Contributor
timestamp: November 26, 2022, 08:33:24 pm
content: Sync E is something else, mostly used in industrial doings to ensure things like motor drives in factories run correctly synchronised.What I am talking about is having the PHY or MAC actually lock an internal timebase to PTP (Not the recovered frame timing like sync E), and exporting that as a reference clock.Most of these parts can ALSO do sync E but you don't need it for this.

author: nctnico
author_rank: Super Contributor
timestamp: November 26, 2022, 08:59:06 pm
content: Quote from: dmills on November 26, 2022, 08:33:24 pmI think you got it the wrong way around. Transferring & recovering the clock by means of the ethernet carrier frequency is precisely what Sync-E is doing! Sync-E is not about recovering frame timing, that is what PTP is for. PTP sends packets (either with hardware or software timestamp) so the timing of an ethernet frame can be determined.Sync-E is mosty done in hardware, PTP is mostly software. FYI: I'm deeply involved in development of equipment that does time & frequency transfer over ethernet down to picosecond levels.