<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 21 Jan 2015, Leonardo Gabrielli wrote:<br>
<br>
> In reality of the 16ms latency I mentioned, 5.3ms are the A/D and 5.3ms are the<br>
> D/A (48khz, 2 periods of 128 samples in JACK at both sides). The remainder<br>
<br>
That does not need to be. My 10 year old P4 was running an ice1712 at<br>
48k/16/2 (.66ms) with no xruns. </blockquote><div><br></div><div>The machine I'm referring to is a Cortex A8 using its own audio codec, and I think the drivers are not exceptional. Lowering the period size was not possible. I was using Debian Stable.</div><div><br></div><div>(going off-topic): what sound card did you use to get the 0.66ms latency and what distro? </div><div><br></div><div>Other comments: network audio requires to serve not only audio card interrupts but also NIC interrupts in case of ethernet, or USB/SPI in case of wifi chips. The drivers must written very carefully. I've often seen the NIC interrupt routine preempt jack audio clients. Furthermore, network drivers are written for throughput, not latency. These two issues make me wonder whether a general purpose OS could serve the purpose well. Or maybe it's just I tend to prefer the low-level solutions...</div><div><br></div><div>One thing yet to check: the original 802.11 specifications allowed for a contention-free period, still have to check whether current 802.11n and 802.1ac AP still allow for it.</div><div><br></div><div>Best,</div><div>Leonardo</div></div></div></div>