Hi all,
The build of qjackctl included with jackdmp for windows is getting really
old.
The biggest problem is that the default "startup time" is set too low,
making it
seem like "jack crashes". (I"ve got many complains that "jack crashes").
Another problem is that you manually have to append "-S" to the "Server
Prefix".
So here:
https://github.com/kmatheussen/qjackctl
...I've cloned the official qjackctl repository, fixed these two problems,
and added some files to make it straight forward to build qjackctl under
mingw32.
(Building is just running the "build_mingw32.sh" script)
Windows binary: http://folk.uio.no/~ksvalast/qjackctl.zip
Perhaps this build, or something similar, can be included in the next
release of jack for windows?
Hello!
Please help.
I installed JACK x64 on my windows 10 x64 and followed the instruction. I
use Overloud TH2 as guitar effects.
I ran Jack PortAudio, and then I turned Overloud TH2 on and selected
JackRouter as device (instead Asio4all I use) and it said that:
Cannot connect to named pipe: = \\. \pipe\client_jack_TH2_0 err = 5
Cannot connect to client pipe
Cannot connect to client name = TH2
Cannot open client
I found out someones answer to that - that I wasn't running Jack as
administrator.
So I did, and now when I select Jack Router as device in TH2 - TH2 shuts
down, saying that it has been stopped (I'm translating the message from a
Russian Windows 10 - so maybe the correct word is "the program has been
terminated"). Then a window comes up saying that (loose translation):
the problem that came up has led to the stop of the program. windows will
close the program, and if there is a known way to fix the problem, will
notify you about it.
This window has a button "close the program" that I press and it closes TH2
down.
This happens every time I run TH2.
How can I fix it?
Hi there,
I have revisited running jackd (2) on a limited resource mips.
Managed to start it running now. Had to limit the number of ports and
alter the postpacked structure alignment in a similar manner for the
__arm__.
It starts and runs :
jackd -p 16 -d alsa -p 256 -i2 -o2
creating alsa driver ... hw:0|hw:0|256|2|48000|2|2|nomon|swmeter|-|32bit
This is great !
However, if I login to the system and try to run anything - the client
fails like so ... whilst jackd keeps running ...
The jackd thread reports :
JackPosixProcessSync::LockedTimedWait error usec = 5000000 err =
Operation timed out
Driver is not running
Cannot create new client
CheckSize error size = 32 Size() = 12
CheckRead error
CheckSize error size = -1 Size() = 4
CheckRead error
CheckSize error size = 0 Size() = 12
CheckRead error
jack_samplerate thread reports :
# jack_samplerate
Cannot read socket fd = 5 err = No error information
CheckRes error
JackSocketClientChannel read fail
Cannot open jack_samplerate client
JackShmReadWritePtr1::~JackShmReadWritePtr1 - Init not done for -1,
skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
skipping unlock
JACK server not running?
and ideas ?
thanks
Matt
Hi all,
I’ve been having a constant noisy signal lately using jacktrip 1.1 and jack audio 0.92 beta3 on El Capitan.
No noise running locally; but always from U.S. to China on ipv6. We’ve even had trouble with initializing an
8 channel stream; had to go with 4. Never had this trouble before.
The connection is virtually jitter-less with 0 packet loss and 80M in the clear.
doing some experiments with jacktrip and Wireshark today - all on the local network.
I find that with larger data chunks (over about 1500k), the packets can be fragmented 2 or 3 times or more.
Where does the fragmenting happen, on sender side? In transit?
Would the machine ever have any problem ‘reassembling” the chunks?
Thanks,
Ken
stereo 48k 24bit connection:
buffer 512
3 FRAGS
OVER IPV6
315345 2454.541857 2001:da8:22b:1506:12dd:b1ff:febd:8a2e 2001:da8:22b:1506:ca2a:14ff:fe34:2beb IPv6 1510 IPv6 fragment (off=0 more=y ident=0xf68b8b47 nxt=17)
315346 2454.541861 2001:da8:22b:1506:12dd:b1ff:febd:8a2e 2001:da8:22b:1506:ca2a:14ff:fe34:2beb IPv6 1510 IPv6 fragment (off=1448 more=y ident=0xf68b8b47 nxt=17)
315347 2454.541863 2001:da8:22b:1506:12dd:b1ff:febd:8a2e 2001:da8:22b:1506:ca2a:14ff:fe34:2beb UDP 262 4464 → 4464 Len=3088 4464 4464
OVER IPV4
488313 2895.589371 10.1.8.32 10.1.8.39 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=2841) [Reassembled in #488315]
488314 2895.589383 10.1.8.32 10.1.8.39 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=2841) [Reassembled in #488315]
488315 2895.589385 10.1.8.32 10.1.8.39 UDP 170 4464 → 4464 Len=3088 4464 4464
[3 IPv4 Fragments (3096 bytes): #744530(1480), #744531(1480), #744532(136)]
[Frame: 744530, payload: 0-1479 (1480 bytes)]
[Frame: 744531, payload: 1480-2959 (1480 bytes)]
[Frame: 744532, payload: 2960-3095 (136 bytes)]
[Fragment count: 3]
[Reassembled IPv4 length: 3096]
[Reassembled IPv4 data: 117011700c18119cc7a5b325e02f050002a7000203180200...]
MONO 44k 16 bit, buffer 128 - NO FRAGS
878806 3832.932229 10.1.8.39 10.1.8.32 UDP 314 4464 → 4464 Len=272 4464 4464
1006386 4103.078745 2001:da8:22b:1506:ca2a:14ff:fe34:2beb 2001:da8:22b:1506:12dd:b1ff:febd:8a2e UDP 334 4465 → 4465 Len=272 4465 4465
STEREO 16 bit, buffer 128 - NO FRAGS
1088352 4253.388686 2001:da8:22b:1506:ca2a:14ff:fe34:2beb 2001:da8:22b:1506:12dd:b1ff:febd:8a2e UDP 590 4464 → 4464 Len=528 4464 4464
Buffer 256 16bit - NO FRAGS
1267127 4884.016193 2001:da8:22b:1506:ca2a:14ff:fe34:2beb 2001:da8:22b:1506:12dd:b1ff:febd:8a2e UDP 1102 4469 → 4469 Len=1040 4469 4469
Buffer 256 24bit - 2 FRAGS
1326725 5095.511528 2001:da8:22b:1506:ca2a:14ff:fe34:2beb 2001:da8:22b:1506:12dd:b1ff:febd:8a2e IPv6 1510 IPv6 fragment (off=0 more=y ident=0x486bd035 nxt=17)
1326726 5095.511529 2001:da8:22b:1506:ca2a:14ff:fe34:2beb 2001:da8:22b:1506:12dd:b1ff:febd:8a2e UDP 174 4471 → 4471 Len=1552 4471 4471
1528363 5497.529358 10.1.8.32 10.1.8.39 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=a448) [Reassembled in #1528364]
1528364 5497.529361 10.1.8.32 10.1.8.39 UDP 114 4473 → 4473 Len=1552 4473 4473
Hi,
we are running a system with two sound cards. The second sound card is
attached to the jackd2 daemon using jack_load audioadapter.
We use a script starting:
aplay -q -D $channel Test-Ton.wav &
arecord -q -D $channel -f S16_LE -r 48000 -c 1 -d 8 $result/recorded.wav
The resulting wav file shows that the time between the start of the recording
and the start of the actual sound continuously increases.
In the beginning (after starting the system up) the time difference is just about 3ms. It increases
constantly to almost one second now
after 8 weeks of uptime.
This happens most significantly on the channels of the second sound card
included by jack_load audioadapter and not noticeable on the first sound card.
The invocation of jackd and jack_load is shown below:
jackd -R -P59 -p 256 -d alsa --device hw:${CARDNUM_0},0 -p 512 --nperiods 3
jack_load -i "-i4 -o4 -q1 -C5 -p512 -n3 -r48000 -d hw:${CARDNUM_1},0"\
jackadapter audioadapter
jackd2 version is: 1.9.8~dfsg.4+20120529git007cdc37-5
I'm, not sure if we a consistent set of options for jackd and
audioadapter.
Do you have a suggestion how we can set things up to prevent the
increase in time difference between recording and playback?
The absolute latency is not critical for us as long as it stays within a
limited range.
Best regards
Michael
To those with access to the web space,
please pull the latest changes from
https://github.com/jackaudio/jackaudio.github.com
In the last weeks and months there have been some changes and
improvements to the site, including:
- more applications in the applications list
- fixes for broken links
- migration work to stay compatible to GitHub pages
- bug fixes and improvements for highlighting of source code and text
- moving some content to the wiki
- a "community network" page, listing mailing lists and wiki
- general maintenance work
I'd like to thank those who submitted pull requests and filed reports.
Your support is much appreciated.
Best regards
Markus
