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
After just checking out jack1 from GitHub and trying to initialize the
git submodules for headers, example-clients and tools I received the
following error:
$ git submodule update --init
fatal: reference is not a tree: e74323c535876abca9a2293bd2ca426a3b91ff8b
fatal: reference is not a tree: a2536c8b348bbfb21ec53db901e7992d7ffef474
fatal: reference is not a tree: 8e140b72de0231d129c6006db969f1dba4f1486b
Unable to checkout 'e74323c535876abca9a2293bd2ca426a3b91ff8b' in
submodule path 'example-clients'
Unable to checkout 'a2536c8b348bbfb21ec53db901e7992d7ffef474' in
submodule path 'jack'
Unable to checkout '8e140b72de0231d129c6006db969f1dba4f1486b' in
submodule path 'tools'
After checking the referenced submodules, I found that the referenced
commits _do not exist_ in the tree of these 3 repositories.
The last change to the submodules was:
> commit c758cdf4f6e959b92683f2dba6ce8617ac4f0a83
> Date: Tue Feb 23 10:15:45 2016 -0500
Which introduced many changes.
What happened here? Are there pending commits of these 3 repositorys
that are not yet public or was there a rebase in these so that the
history got rewritten?
For the time being, I assume it is safe to assume that HEAD of master is
a valid commit to check out?
Best regards
Markus
Hi,
there was this mesage on github announcing simplified handling of large
files in repos, "large file supprt". I wondered if this could replace the
dropbox links of the binaries for future releases.
cheers
Thomas