January 2017 - JackAudio - lists.linuxaudio.org

[Jack-Devel] Cannot combine audio devices with more than 64 channels

by Jörg Müller

I need to combine two HDSPe MADI FX cards to one virtual device. I have a working driver, which is alsa-compatible. I can select each single card in any alsa-compatible application and all channels work flawless. For combining the MADI FX cards to one virtual device, I created an .asoundrc with 194 inputs for each card. When I start that virtual device via jackd -R -d alsa -C madifx_record_all -P madifx_playback_all I get this error: > creating alsa driver ... > madifx_playback_all|madifx_record_all|1024|2|48000|0|0|nomon|swmeter|-|32bit > jackd: pcm_multi.c:1060: snd_pcm_multi_open: Assertion `!slave_map[sidxs[i]][schannels[i]]' failed. However, it works when I reduce the amount from 194 to 64 channels per card. I tried to use 128 channels per card, but that fails the same way. See my alsa-info attached, which also includes the .asoundrc content. I also found this, which might be related: https://ccrma.stanford.edu/mirrors/lalists/lad/2005/06/0202.html To me, this looks like a bug. What do you think?

5 years, 8 months

11
29
0 0

Re: [Jack-Devel] Fwd: hi from MONGOLIA

by Neil C Smith

Hi, On 29 January 2017 at 06:57, ganaa tomor <ganaa0323(a)gmail.com> wrote: > But i can't run jnajack because i am beginner. Can you help me to run it on > the raspberry pi. > I need a video tutorial... Sorry, I'm not in a position to do that. What you really need to do is look at some NetBeans / Maven tutorials anyway. It should be fairly easy to checkout the JNAJack and examples repositories and get them to work once you've got your head around that. Best wishes, Neil -- Neil C Smith Artist & Technologist www.neilcsmith.net Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

6 years, 2 months

1
0
0 0

[Jack-Devel] Fwd: hi from MONGOLIA

by ganaa tomor

hi. how are you ? I have a some question about JJack – Using the JACK Audio Connection Kit with Java. i can't run it from source code using Netbeans (Java editor). can you send me video tutorial how to run this JJack tutorial ? my purpose is to get data from midi keyboard using Rasbian (Raspberry pi OS ) is it possible ? PLEASE PLEASE PLEASE HELP ME

6 years, 2 months

2
1
0 0

Re: [Jack-Devel] Cannot combine audio devices with more than 64 channels

by Chris Caudle

On Tue, January 24, 2017 1:45 pm, Fons Adriaensen wrote: > Without resampling the samples will not be modified, but the latency of the two cards will not be the same (but the difference will be repeatable). Meaning some output ports will have more latency than others? I don't think jack has a way to notify the server that some backends have different latency so that it can be reported to applications like Ardour that adjust for latency. -- Chris Caudle

6 years, 2 months

3
2
0 0

[Jack-Devel] Selecting Firewire Interface with -d

by Thomas Brand

Hi, after some research and help from the ffado list i think that the JACK 2's firewire backend implementation does not honor the -d command line flag to set a specific interface. The effect is that when multiple devices are present, no matter what -d is set to, all devices are aggregated. In most cases this fine and wanted. However there is no warning or error message for bogus -dhw arguments and it's not possible to start one specific interface only without workarounds. With the following diff (just 3 lines from JACK 1 codebase) it works as expected, even using guid:xxx (which is a very nice feature). Please review and consider merge. Thanks, Thomas

6 years, 2 months

3
7
0 0

[Jack-Devel] jack-headers merge ( the future of JACK(2))

by micu

Hello dear friends (and enemies) of JACK1, JACK2, netJACK, jackDBUS, ... Recently I tool the plunge and did a diff between <https://github.com/jackaudio/headers> (the one from jack1) and <https://github.com/jackaudio/jack2/tree/master/common/jack> to realize that the diff isn't actually as bad I feared it would be. I quickly glanced through the differences, and most of what I found looks like it shouldn't be too hard to fix (sth. like jackctl_sigmask_t being defined as an opaque type in JACK2 etc.). I'd like to offer my precious time for giving a jack-headers merge another shot (I know Paul asked for some help on that already in 2012...). As a first step I'd suggest moving the current JACK2 headers to its own branch in <https://github.com/jackaudio/headers> and start using the headers repository in JACK2, as well. But before I start digging into the work, I'd like to ask whether you'd be actually interested in that? (Or in other words: whether someone is there to review and merge the PR ;) I noticed some open pull requests are lingering in the JACK2 repository and I wonder whether the development of JACK2 is stalled?) Apart from that I'd like to ask a more generic question about the future of JACK(2): As Paul mentioned in his step down notice, many GNU/Linux distributions nowadays use JACK2 by default, and on Windows and OSX I'd personally rather recommend using JACK2. In other words, I myself still am a JACK2 fan naturally ;) (which doesn't mean I am against JACK1 or sth. like that). Paul mentioned some people having criticism about the JACK2 design, but I wasn't able to find any information about the specific points of criticism. Could you maybe provide me with some resources about that (links to blogs, mailing list posts)? Don't get me wrong: I please do NOT want to start a flame war here, but I'd like to gain a better picture of the current situation. Kind regards, micu -- OpenPGP / GnuPG: 0xE4CB4E80 Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80 <<</>> http://www.micuintus.de

6 years, 2 months

5
6
0 0

[Jack-Devel] a2jmidi and jack

by andrea

I have a question about a2jmidi since I was trying to see if I can live without it to simplify setup. I am using Jack 1.9.10 JACK has 2 MIDI drivers: raw and seq. I would like to connect both 1) hardware MIDI ports (i.e. a USB midi cable 2) software MIDI ports (i.e. fluidsynth) I seem to be able to do it without a2jmidi for the former but have not managed with the latter. And, when I have a choice, what is the best option: opinions out there aren't uniform on this. By best I mean the most time accurate. Regards

6 years, 2 months

2
1
0 0

Re: [Jack-Devel] Recorded from OSS /dev/dsp sound is too high pitched on FreeBSD

by Adrian Knoth

On Tue, Jan 10, 2017 at 11:38:56AM +0100, Hans Petter Selasky wrote: > >>I'm using jack1 almost every week with FreeBSD and OSS. I would happily be > >>glad to contribute a better OSS experience with FreeBSD, where OSS is the > >>de-facto audio standard. Maybe you could give some FreeBSD devs a few src > >>bits for jack1? > >What do you need specifically? The generic entry point would be > > https://github.com/jackaudio/jack1 > If you want to add me to the devs team, my github nick is "hselasky" Looking forward to your contributions! Let's start with pull requests, so that we can discuss patches prior to merging them. Cheers -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

6 years, 2 months

2
1
0 0

[Jack-Devel] [Fwd: strange valgrind results for client initialization and shutdown]

by Thomas Brand

Hi list, i have recently started to play with valgrind and for yet unknown reasons i get a lot of "Syscall param write(buf) points to uninitialised byte(s)" even for a simple program like this: #include <jack/jack.h> int main() { const char *name="test"; jack_client_t *client; jack_options_t options=JackNoStartServer; jack_status_t status; client=jack_client_open(name,options,&status); jack_client_close(client); return 0; } //gcc -o test test.c -ljack //valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -v ./test Is there anything missing in the code example? Should i worry about the errors shown by valgrind (in that case 10 errors from 6 contexts) at all? Thanks for your suggestions. Thomas ------ amend: sorry that was too quick, it's 2 errors in 2 contexts. The above applies to jack_simple_client. I hope it's convenient to paste output here, so here is the output for test.c: ==11355== Memcheck, a memory error detector ==11355== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==11355== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==11355== Command: ./test ==11355== --11355-- Valgrind options: --11355-- --leak-check=full --11355-- --show-leak-kinds=all --11355-- --track-origins=yes --11355-- -v --11355-- Contents of /proc/version: --11355-- Linux version 3.13.0-88-lowlatency (buildd@lgw01-16) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #135-Ubuntu SMP PREEMPT Wed Jun 8 22:20:04 UTC 2016 --11355-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3 --11355-- Page sizes: currently 4096, max supported 4096 --11355-- Valgrind library directory: /usr/lib/valgrind --11355-- Reading syms from /tmp/test --11355-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/ld-2.19.so .. --11355-- .. CRC mismatch (computed 46abf574 wanted 3ca2d3ca) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --11355-- Considering /usr/lib/valgrind/memcheck-amd64-linux .. --11355-- .. CRC mismatch (computed 4f1eed43 wanted a323a3ab) --11355-- object doesn't have a symbol table --11355-- object doesn't have a dynamic symbol table --11355-- Scheduler: using generic scheduler lock implementation. --11355-- Reading suppressions file: /usr/lib/valgrind/default.supp ==11355== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-11355-by-srv-on-??? ==11355== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-11355-by-srv-on-??? ==11355== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-11355-by-srv-on-??? ==11355== ==11355== TO CONTROL THIS PROCESS USING vgdb (which you probably ==11355== don't want to do, unless you know exactly what you're doing, ==11355== or are doing some strange experiment): ==11355== /usr/lib/valgrind/../../bin/vgdb --pid=11355 ...command... ==11355== ==11355== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==11355== /path/to/gdb ./test ==11355== and then give GDB the following command ==11355== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=11355 ==11355== --pid is optional if only one valgrind process is running ==11355== --11355-- REDIR: 0x4019c50 (ld-linux-x86-64.so.2:strlen) redirected to 0x380764b1 (???) --11355-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --11355-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --11355-- .. CRC mismatch (computed fc68135e wanted 45f5e986) --11355-- object doesn't have a symbol table --11355-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so --11355-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so .. --11355-- .. CRC mismatch (computed ae683f7e wanted 08c06df2) --11355-- object doesn't have a symbol table ==11355== WARNING: new redirection conflicts with existing -- ignoring it --11355-- old: 0x04019c50 (strlen ) R-> (0000.0) 0x380764b1 ??? --11355-- new: 0x04019c50 (strlen ) R-> (2007.0) 0x04c2e1a0 strlen --11355-- REDIR: 0x4019a00 (ld-linux-x86-64.so.2:index) redirected to 0x4c2dd50 (index) --11355-- REDIR: 0x4019c20 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2f2f0 (strcmp) --11355-- REDIR: 0x401a970 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c31da0 (mempcpy) --11355-- Reading syms from /usr/local/lib/libjack.so.0.1.0 --11355-- Reading syms from /lib/x86_64-linux-gnu/libc-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/libc-2.19.so .. --11355-- .. CRC mismatch (computed ac9b5ddb wanted a10d05bf) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/libpthread-2.19.so .. --11355-- .. CRC mismatch (computed 88040ace wanted 71b58165) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /lib/x86_64-linux-gnu/librt-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/librt-2.19.so .. --11355-- .. CRC mismatch (computed 9efd3dd5 wanted ae0f290f) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/librt-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /lib/x86_64-linux-gnu/libdl-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/libdl-2.19.so .. --11355-- .. CRC mismatch (computed 5e07a82d wanted c608f377) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 --11355-- Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 .. --11355-- .. CRC mismatch (computed dc37bb90 wanted ea8c3b40) --11355-- object doesn't have a symbol table --11355-- Reading syms from /lib/x86_64-linux-gnu/libm-2.19.so --11355-- Considering /lib/x86_64-linux-gnu/libm-2.19.so .. --11355-- .. CRC mismatch (computed 08659659 wanted 7ce1b39a) --11355-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.19.so .. --11355-- .. CRC is valid --11355-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1 --11355-- Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 .. --11355-- .. CRC mismatch (computed 6116126e wanted 54e3f1f2) --11355-- object doesn't have a symbol table --11355-- REDIR: 0x511cc50 (libc.so.6:strcasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x511ef40 (libc.so.6:strncasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x511c420 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x511a6b0 (libc.so.6:rindex) redirected to 0x4c2da30 (rindex) --11355-- REDIR: 0x51189b0 (libc.so.6:strlen) redirected to 0x4c2e0e0 (strlen) --11355-- REDIR: 0x511be90 (libc.so.6:__GI_memcmp) redirected to 0x4c30b80 (__GI_memcmp) --11355-- REDIR: 0x5116f60 (libc.so.6:strcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x5127c10 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c2f1b0 (strcmp) --11355-- REDIR: 0x5addd90 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2b070 (operator new(unsigned long)) --11355-- REDIR: 0x511c4b0 (libc.so.6:memset) redirected to 0x4c31350 (memset) --11355-- REDIR: 0x5113130 (libc.so.6:calloc) redirected to 0x4c2cbf0 (calloc) --11355-- REDIR: 0x5112d00 (libc.so.6:free) redirected to 0x4c2bd80 (free) --11355-- REDIR: 0x51239b0 (libc.so.6:strchrnul) redirected to 0x4c319b0 (strchrnul) --11355-- REDIR: 0x5adc0f0 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2c250 (operator delete(void*)) --11355-- REDIR: 0x511a670 (libc.so.6:strncpy) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x512d0b0 (libc.so.6:__strncpy_sse2_unaligned) redirected to 0x4c2e770 (__strncpy_sse2_unaligned) ==11355== Syscall param write(buf) points to uninitialised byte(s) ==11355== at 0x517B72D: ??? (syscall-template.S:81) ==11355== by 0x4E6F131: Jack::JackClientSocket::Write(void*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5CA93: Jack::JackClientCheckRequest::Write(Jack::detail::JackChannelTransactionInterface*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5A916: Jack::JackGenericClientChannel::ServerSyncCall(Jack::JackRequest*, Jack::JackResult*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5AB36: Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71F67: Jack::JackSocketClientChannel::Open(char const*, char const*, int, char*, Jack::JackClient*, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E6FFE3: Jack::JackLibClient::Open(char const*, char const*, int, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71172: jack_client_open_aux(char const*, JackOptions, JackStatus*, __va_list_tag*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E712FE: jack_client_open (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x40071D: main (in /tmp/test) ==11355== Address 0xffefffb85 is on thread 1's stack ==11355== in frame #4, created by Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (???) ==11355== Uninitialised value was created by a stack allocation ==11355== at 0x4E5AA7E: Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== --11355-- REDIR: 0x51183f0 (libc.so.6:strcpy) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x512ca80 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c2e1c0 (strcpy) ==11355== Syscall param write(buf) points to uninitialised byte(s) ==11355== at 0x517B72D: ??? (syscall-template.S:81) ==11355== by 0x4E6F131: Jack::JackClientSocket::Write(void*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5D07D: Jack::JackClientOpenRequest::Write(Jack::detail::JackChannelTransactionInterface*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5A916: Jack::JackGenericClientChannel::ServerSyncCall(Jack::JackRequest*, Jack::JackResult*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5AC79: Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E7009D: Jack::JackLibClient::Open(char const*, char const*, int, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71172: jack_client_open_aux(char const*, JackOptions, JackStatus*, __va_list_tag*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E712FE: jack_client_open (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x40071D: main (in /tmp/test) ==11355== Address 0xffefffbfd is on thread 1's stack ==11355== in frame #4, created by Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (???) ==11355== Uninitialised value was created by a stack allocation ==11355== at 0x4E5ABD2: Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== --11355-- REDIR: 0x511c5b0 (libc.so.6:mempcpy) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x51dd1c0 (libc.so.6:__mempcpy_ssse3_back) redirected to 0x4c31ad0 (mempcpy) --11355-- REDIR: 0x5121620 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x5127ec0 (libc.so.6:__memcpy_sse2_unaligned) redirected to 0x4c2f6b0 (memcpy@@GLIBC_2.14) --11355-- REDIR: 0x5112660 (libc.so.6:malloc) redirected to 0x4c2ab10 (malloc) --11355-- REDIR: 0x5116d10 (libc.so.6:index) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --11355-- REDIR: 0x5116d40 (libc.so.6:__GI_strchr) redirected to 0x4c2db90 (__GI_strchr) ==11355== ==11355== HEAP SUMMARY: ==11355== in use at exit: 96 bytes in 2 blocks ==11355== total heap usage: 18 allocs, 16 frees, 53,088 bytes allocated ==11355== ==11355== Searching for pointers to 2 not-freed blocks ==11355== Checked 307,624 bytes ==11355== ==11355== 48 bytes in 1 blocks are still reachable in loss record 1 of 2 ==11355== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11355== by 0x4E650AA: __static_initialization_and_destruction_0(int, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E6512C: _GLOBAL__sub_I_JackGlobals.cpp (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4010109: call_init.part.0 (dl-init.c:78) ==11355== by 0x40101F2: call_init (dl-init.c:36) ==11355== by 0x40101F2: _dl_init (dl-init.c:126) ==11355== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) ==11355== ==11355== 48 bytes in 1 blocks are still reachable in loss record 2 of 2 ==11355== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11355== by 0x4E650CB: __static_initialization_and_destruction_0(int, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E6512C: _GLOBAL__sub_I_JackGlobals.cpp (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4010109: call_init.part.0 (dl-init.c:78) ==11355== by 0x40101F2: call_init (dl-init.c:36) ==11355== by 0x40101F2: _dl_init (dl-init.c:126) ==11355== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) ==11355== ==11355== LEAK SUMMARY: ==11355== definitely lost: 0 bytes in 0 blocks ==11355== indirectly lost: 0 bytes in 0 blocks ==11355== possibly lost: 0 bytes in 0 blocks ==11355== still reachable: 96 bytes in 2 blocks ==11355== suppressed: 0 bytes in 0 blocks ==11355== ==11355== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ==11355== ==11355== 1 errors in context 1 of 2: ==11355== Syscall param write(buf) points to uninitialised byte(s) ==11355== at 0x517B72D: ??? (syscall-template.S:81) ==11355== by 0x4E6F131: Jack::JackClientSocket::Write(void*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5D07D: Jack::JackClientOpenRequest::Write(Jack::detail::JackChannelTransactionInterface*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5A916: Jack::JackGenericClientChannel::ServerSyncCall(Jack::JackRequest*, Jack::JackResult*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5AC79: Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E7009D: Jack::JackLibClient::Open(char const*, char const*, int, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71172: jack_client_open_aux(char const*, JackOptions, JackStatus*, __va_list_tag*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E712FE: jack_client_open (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x40071D: main (in /tmp/test) ==11355== Address 0xffefffbfd is on thread 1's stack ==11355== in frame #4, created by Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (???) ==11355== Uninitialised value was created by a stack allocation ==11355== at 0x4E5ABD2: Jack::JackGenericClientChannel::ClientOpen(char const*, int, int, int*, int*, int*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== ==11355== ==11355== 1 errors in context 2 of 2: ==11355== Syscall param write(buf) points to uninitialised byte(s) ==11355== at 0x517B72D: ??? (syscall-template.S:81) ==11355== by 0x4E6F131: Jack::JackClientSocket::Write(void*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5CA93: Jack::JackClientCheckRequest::Write(Jack::detail::JackChannelTransactionInterface*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5A916: Jack::JackGenericClientChannel::ServerSyncCall(Jack::JackRequest*, Jack::JackResult*, int*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E5AB36: Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71F67: Jack::JackSocketClientChannel::Open(char const*, char const*, int, char*, Jack::JackClient*, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E6FFE3: Jack::JackLibClient::Open(char const*, char const*, int, JackOptions, JackStatus*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E71172: jack_client_open_aux(char const*, JackOptions, JackStatus*, __va_list_tag*) (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x4E712FE: jack_client_open (in /usr/local/lib/libjack.so.0.1.0) ==11355== by 0x40071D: main (in /tmp/test) ==11355== Address 0xffefffb85 is on thread 1's stack ==11355== in frame #4, created by Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (???) ==11355== Uninitialised value was created by a stack allocation ==11355== at 0x4E5AA7E: Jack::JackGenericClientChannel::ClientCheck(char const*, int, char*, int, int, int*, int*, int) (in /usr/local/lib/libjack.so.0.1.0) ==11355== ==11355== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ---

6 years, 2 months

1
0
0 0

[Jack-Devel] strange valgrind results for client initialization and shutdown

by Thomas Brand

Hi list, i have recently started to play with valgrind and for yet unknown reasons i get a lot of "Syscall param write(buf) points to uninitialised byte(s)" even for a simple program like this: #include <jack/jack.h> int main() { const char *name="test"; jack_client_t *client; jack_options_t options=JackNoStartServer; jack_status_t status; client=jack_client_open(name,options,&status); jack_client_close(client); return 0; } //gcc -o test test.c -ljack //valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -v ./test Is there anything missing in the code example? Should i worry about the errors shown by valgrind (in that case 10 errors from 6 contexts) at all? Thanks for your suggestions. Thomas

6 years, 2 months

1
0
0 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

JackAudio January 2017