Hacker News Reader

I think I'm going to have to make a blog post addressing some of the clocking questions that come up. My brief answer for now is that there is only one clock, and that is the ETH-68 clock. The overall data flow is push based; the arrival of a new buffer of data at the Linux host IS the clocking event that schedules an audio graph evaluation. There is no need for another clock on the Linux host.

View on HN

Unless audio is sampled at ETH-68 clock this won't work for long periods. Except if you are tuning a loop continuously doing continuous resampling using a Farrow filter for example.

In my comment that you replied to, I outlined a scenario where the only clock is the ETH-68 clock, so yes audio is sampled at the ETH-68 clock.

See my other comment in this thread about resampling with PipeWire or JACK.

> There is no need for another clock on the Linux host

surely that works only as long as eth68 is the only interface? but often you might want other interfaces too which inherently have their own clocks

That is sort of true, although it should be possible to take advantage of the resampler in PipeWire or JACK (zalsa_in/zalsa_out) to effectively get multiple interfaces in the same graph. I would expect some hit to the audio latency when going through the resampler.

Reply on news.ycombinator.com