[Jack-Devel] ?==?utf-8?q? Looking for help setting up NetJack over WLAN from a Windoze box

[Ralf Mattes]

Am Montag, 29. Mai 2017 03:49 CEST, Kenneth Fields <syneme.lab at 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 at lists.jackaudio.org
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> 
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel at lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org