23 May
2017
23 May
'17
9:51 a.m.
Hi all,
I'm running into issues with a project that uses JACK and would
appreciate help or pointers therewith.
The basic premise is as follows: I want to use JACK to transfer audio
from a _Windows slave_ to a _Linux master_.
I've been using the latest JACK distro I could find (1.9.10). I've
successfully got it to run using NetJack2 (with `jack_load netmanager`
on the master and `jackd -d net` on the slave). It works great...
...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.
I've tried to tinker with the options to get it to work better (say, at
the cost of latency), but with no success. If anyone has pointers has to
how to improve the setup with NetJack2 in order for it to work over
WLAN, they would be greatly appreciated.
That being said, reading the doc and looking around the web for info
suggests it might very well be the case that NetJack2 simply isn't
suited for WLAN transport. Indeed, some resources indicate that NetJack1
would be more adapted.
Trouble with that, then, is that, at least in the distro I got, NetJack1
doesn't work on Windows. Trying to start it yields the following error:
netjack_poll not implemented
, after which the program exits.
I've seen a thread (I believe on this list) indicating that at least
some people were aware of the issue, although no solution was provided.
Given that that thread was a bit old, and assuming the above conclusion
-- that NetJack2 isn't suited to wireless -- is correct, I guess my
question boils down to:
Can anyone tell me how I can get NetJack1 work on Windows?
Many thanks in advance, although will have some left for later,
mc.
23 May
23 May
11:22 a.m.
New subject: [Jack-Devel] Looking for help setting up NetJack over WLAN from a Windoze box
On 23.05.2017 16:50, jack-devel(a)malikc.neomailbox.net 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.
That being said, reading the doc and looking around
the web for info
suggests it might very well be the case that NetJack2 simply isn't
suited for WLAN transport. Indeed, some resources indicate that NetJack1
would be more adapted.
Same problem there...
[1]
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Net…
12:48 p.m.
New subject: [Jack-Devel] Looking for help setting up NetJack over WLAN from a Windoze box
On 2017-05-23 18:22, Hanspeter Portner wrote:
On 23.05.2017 16:50, jack-devel(a)malikc.neomailbox.net
wrote:
Thanks for the reply!
So your view is that packet loss is the cause? I had naïvely 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. I wouldn't have expected that; although at the same
time I'm no networking expert...
If so, then I guess what you're saying is that there's simply no way to
leverage NetJack, whether NetJack1 or NetJack2, for transport over
wireless?
Regards,
mc.
...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.
That being said, reading the doc and looking
around the web for info
suggests it might very well be the case that NetJack2 simply isn't
suited for WLAN transport. Indeed, some resources indicate that NetJack1
would be more adapted.
Same problem there...
[1]
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Net…
28 May
28 May
6:47 p.m.
New subject: [Jack-Devel] Looking for help setting up NetJack over WLAN from a Windoze box
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
8:49 p.m.
New subject: [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
<chris(a)chriscaudle.org> 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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org 
29 May
29 May
2:54 a.m.
New subject: [Jack-Devel] ?==?utf-8?q? Looking for help setting up NetJack over WLAN from a Windoze box
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
6 Jun
6 Jun
9:35 a.m.
New subject: [Jack-Devel] Looking for help setting up NetJack over WLAN from a Windoze box
All,
Thank you very much for you inputs.
A fair point. The reason I had been focussing on packet loss vs.
congestion is because I had read somewhere that you could have different
transport characteristics depending on whether you were using unicast or
multi/broadcast; differences which might be in play if the problem were
congestion, but not if it were packet loss. Since (correct me if I'm
wrong) NetJack1 uses unicast, whereas NetJack2 uses broad/multicast,
trying NetJack1 would have offered a possible, and close-by, solution. I
was merely trying to tailor the problem to what seemed like the
lowest-hanging solutions. But this is moot now.
.-.
I'm currently rewriting my software and abstracting out the transport,
which I'll do myself instead of relying on Jack (Jack will still be
digesting the audio on the endpoint; just not transporting it there).
Once the framework is in place, I want to try with a simple TCP
transport and see what kind of reliability and latency I can achieve
with that. Perhaps it'll be workable, perhaps not. I can't really afford
the behaviour of the more common over-the-air music players which, as
Chris pointed out, will buffer quite heftily to achieve reliability.
Further on, I'd also like to try something like SCTP
(<https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol>)
and see what gives -- although the Windoze support for that seems
sketchy, at best.
--
MC.
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.
I have run an analyser on my network, and I'm indeed getting a
horrendous (to the naive) amount of packet loss. Given that, it makes
perfect sense that jackd wouldn't be able to get coherent audio together.
>> 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.
2517
days inactive
2531
days old
jackaudio@lists.linuxaudio.org
6 comments
6 participants
participants (6)
-
Chris Caudle -
Hanspeter Portner -
jack-devel＠malikc.neomailbox.net -
Kenneth Fields -
Malik Costet
-
Ralf Mattes