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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
