29 May
2017
29 May
'17
2:54 a.m.
Am Montag, 29. Mai 2017 03:49 CEST, Kenneth Fields <syneme.lab(a)gmail.com> schrieb:
Hi,
I think audio over wi-fi is a non-starter. it will never be glitch free.
I’m rewiring my own studio at the moment with fast router and cat 7 ethernet.
I use Artsmesh (MacOS) to route all the audio/video in the studio and over the internet
(uses jack/jacktrip, ffmpeg/syphon) and has a better interface than qjackctl.
Hmm - sounds very interesting. Thank's for pointing this out.
>> So your view is that packet loss is the
cause? I had naively assumed it
>> might be due to latency or congestion, but packet loss would make a lot
>> of sense.
In realtime audio a package congestion IS a lost packagage. It doesn't make sense
to resend a package that should have been played in the past.
>> Although -- I hadn't mentioned this
explicitly, but my setup
>> is with both boxes connected on the same local network, in other words
>> both to the same WiFi router;
Both clients send on the same channel - i.e. block each other. WiFi is, by it's very
nature, half-duplex, only one client can send (after all, there's a reason why they
called it ETHER-net ... ;-)
>> can there really be such a dramatic amount
>> of packet loss in that context for the result to be completely garbled
>> sound? I'm not talking about clicks here and there, but really little
>> better than static.
A package too late is a package not played ....
If the sound is always garbled, it never even starts out with decent
quality, then you may be right, latency could be causing every cycle to
not have enough time. Do you get a lot of under-run notifications when
starting? If latency is the only problem you may be able to set a larger
number of network cycles and get around that.
You should be able to get some packet loss statistics from ifconfig, it
would be worth checking to see if there are lots of RX errors or RX
dropped notifications. I don't know how well that information is gathered
for UDP packets, so using iperf to generate traffic and then looking how
many dropped packets were detected would be good. You could probably get
an idea from iperf of the average and maximum latency as well.
In general real time audio transmission over Wi-Fi is going to be
difficult. I have no trouble streaming FLAC files to music players over
Wi-Fi, but those buffer over half a second of audio, and are using TCP so
the TCP layer will just send again any packets which get dropped. When
using jack the network connection has to be able to send packets reliably
with low latency, and no matter what you do Wi-Fi is still going to be a
shared medium, so every time another device anywhere in the local vicinity
transmits, your devices are going to have to listen to see if they need to
switch to a different channel, or pause to allow fair time for another
device. That other device might belong to your neighbor, so you can't
assume that just because you have only two devices connected to your
router that there will not be other interference.
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org