[LAU] Audio over WIFI

[Len Ovens]

On Fri, 23 Jan 2015, Leonardo Gabrielli wrote:

> 
>  
>       On Wed, 21 Jan 2015, Leonardo Gabrielli wrote:
>
>       > In reality of the 16ms latency I mentioned, 5.3ms are the A/D and
>       5.3ms are the
>       > D/A (48khz, 2 periods of 128 samples in JACK at both sides). The
>       remainder
>
>       That does not need to be. My 10 year old P4 was running an ice1712 at
>       48k/16/2 (.66ms) with no xruns. 
> 
> 
> 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.

I have found that USB audio IFs generally can get to 64/2, but the INTEL 
(on board) IFs seem to need 64/3. I have heard that Firewire IFs can do at 
least 32/2.

> (going off-topic): what sound card did you use to get the 0.66ms latency and what
> distro? 

I was running UbuntuStudio (lowlatency kernel) and the card is a Delta 66 
which has the ice1712 chip inside (quite common back then for multitrack) 
and is a PCI audio card. My ensoniq ens1370 based PCI card does not go 
that low, but can at least do 32/2. The .66ms is one way and does not 
include the ADC delay which on that IF is higher than the jack/alsa 
induced latency.

> 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 audio card would be prioritized as it gets hit three times as often. 
NICs are not a problem in my experience, wireless is something else. With 
the wireless stuff, a lot of the WIFI radios seem to make use of the 
system CPU for things like running a channel scan and this as able to 
disrupt audio. This is why I think a second cpu/core that just deals with 
the wifi and looks to the system like a NIC would be the way to go. The 
faster NICs do this I think. The system just loads and empties buffers, 
the NIC takes care of all timing and streaming. WIFI should be the same 
way.

> 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...

The NIC should be able to be at a lower priority. What little I have done 
with netjack and just general networking has not shown my NIC to cause 
problems with audio. Latency/throughput in the NIC can be adjusted by 
limiting packet size. The old standard of 1500 as an MTU is fine. This can 
be set once for the whole network at the DHCP server... There is a new 
(well newer) standard for bigger packet size, but not many people use it. 
The NIC is not that complex and the driver should honor QOS of a packet. 
Once a packet goes into the NIC, it is sent with no help from the cpu or 
delay. The problem of delay would be another application filling up the 
NIC driver's que with low priority data. Most things that support QOS use 
more than one que to get around this. I don't know if the linux network 
driver does this or not. But limiting other applications would have a 
similar effect  :)

In the end, it is the wireless link that is needing the most work. 
Rewriting the driver to make sure it never blocks the CPU for longer than 
1ms (maybe a little less) would make a big difference. In fact, that would 
be helpful to the whole Linux audio world if WIFI was being used for 
streaming or not. USB3 WIFI dongles may be better than internal... but I 
am not holding my breath.

So far as AES67 on linux is concerned, I can not ever see a linux box 
being a clock master or even being able to sync a local audio IF to 
another clock. If the local ADC/DAC does not have some external sync from 
the master clock then there would have to be some sort of resample step as 
well. Some NICs can have a built in clock that could server as a media 
clock... but they are not (yet) cheap.


--
Len Ovens
www.ovenwerks.net