On 10/25/2012 04:54 PM, Jannis Achstetter wrote: > Hi Fons, hi list, > > I've been trying to get zita-a2jbridge working on my laptop. JACK is > running with the internal Intel HDA-card via ALSA backend. > Using the Edirol UA-101 as JACK's main-backend works w/o problems and > using alsa_out & alsa_in works, too. > Software versions I am using: > media-libs/zita-alsa-pcmi-0.2.0 > media-libs/zita-resampler-1.2.0 > media-sound/zita-ajbridge-0.2.2 > media-sound/jack-audio-connection-kit-1.9.8 > > Here's the output of gdb trying to run zita-j2a: > kripton@miramis ~ $ cat /proc/asound/cards > 0 [Intel ]: HDA-Intel - HDA Intel > HDA Intel at 0xfc020000 irq 46 > 1 [Loopback ]: Loopback - Loopback > Loopback 1 > 2 [UA101 ]: UA-101 - UA-101 > EDIROL UA-101 (serial ZT40539), 48000 Hz at > usb-0000:00:1d.7-2, high speed > 29 [ThinkPadEC ]: ThinkPad EC - ThinkPad Console Audio Control > ThinkPad Console Audio Control at EC reg 0x30, fw > 7VHT16WW-1.06 > kripton@miramis ~ $ gdb zita-j2a > GNU gdb (Gentoo 7.5 p1) 7.5 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > For bug reporting instructions, please see: > <http://bugs.gentoo.org/>... > Reading symbols from /usr/bin/zita-j2a...done. > (gdb) r -j UA101 -d hw:UA101 -c 10 -v > Starting program: /usr/bin/zita-j2a -j UA101 -d hw:UA101 -c 10 -v > warning: Could not load shared library symbols for linux-vdso.so.1. > Do you need "set solib-search-path" or "set sysroot"? > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > playback : > nchan : 10 > fsamp : 48000 > fsize : 256 > nfrag : 2 > format : S32_LE > capture : not enabled > [New Thread 0x7ffff7f9f700 (LWP 15169)] > [New Thread 0x7ffff7f1e700 (LWP 15170)] > [New Thread 0x7ffff7e9d700 (LWP 15171)] > [New Thread 0x7ffff7fce700 (LWP 15172)] > Starting synchronisation. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff7e9d700 (LWP 15171)] > 0x00007ffff7bd8760 in VResampler::process (this=0x6265a0) at > vresampler.cc:217 > 217 vresampler.cc: No such file or directory. > (gdb) bt > #0 0x00007ffff7bd8760 in VResampler::process (this=0x6265a0) at > vresampler.cc:217 > #1 0x0000000000403951 in Jackclient::playback (this=0x6262d0, > nframes=128) at jackclient.cc:222 > #2 0x00000000004042eb in Jackclient::jack_process (this=0x6262d0, > nframes=128) at jackclient.cc:467 > #3 0x00007ffff779c61a in ?? () from /usr/lib64/libjack.so.0 > #4 0x00007ffff77af760 in ?? () from /usr/lib64/libjack.so.0 > #5 0x00007ffff7575ec6 in start_thread () from /lib64/libpthread.so.0 > #6 0x00007ffff6aa08ad in clone () from /lib64/libc.so.6 > (gdb) q > A debugging session is active. > > Inferior 1 [process 15160] will be killed. > > Quit anyway? (y or n) y > > Any ideas? > Classic race condition. The jack_client is activated before the resampler is initialized. zita-j2a.cc:200 creates the jack-client and calls jack_activate. process_callbacks can arrive starting now. but not until zita-j2a.cc:211 calls J->start() the data-structures required to do the processing are initialized. Easiest solution is probably to check if start() has been called in the process callback: --- a/jackclient.cc +++ b/jackclient.cc @@ -301,6 +301,8 @@ int Jackclient::jack_process (int nframes) jack_nframes_t ft; double tj, err, d1, d2; + if (_state == INIT) return 0; + // Buffer size change or other evil. if (_state == TERM) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
