Re: [Jack-Devel] Looking for help setting up NetJack over WLAN from a Windoze box

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.

Ken



> On May 29, 2017, at 7:47 AM, Chris Caudle <[hidden]> wrote:
> 
> On Tue, May 23, 2017 12:47 pm, Malik Costet wrote:
>> On 2017-05-23 18:22, Hanspeter Portner wrote:
>>>> ...But it only works great over Ethernet. And I'd very much like it to
>>>> work over WLAN, which it doesn't. Over wireless, the sound is
>>>> completely garbled. AFAICT, it's a network issue.
>>> 
>>> NetJACK sends its audio data via UDP [1], e.g. there's no resending of
>>> lost
>>> packets like in TCP. If packets are lost (which is *very* likely over
>>> wireless), the packets are really lost and you miss a chunk of audio
>>> frames, hence your garbled sound at the receiver.
> 
>> 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. 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; 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.
> 
> 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
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

1496022578.13103_0.ltw:2,a <2E522DF6-E8D2-4809-AB85-8C913279D20B at gmail dot com>