25 Oct
2012
25 Oct
'12
4:54 p.m.
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?
Thanks in advance,
Jannis
25 Oct
25 Oct
5:23 p.m.
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)
5:49 p.m.
Am 25.10.2012 17:23, schrieb Robin Gareus:
On 10/25/2012 04:54 PM, Jannis Achstetter wrote:
Sounds reasonable but still crashes with the same error. I'll try to
debug this further :)
[...]
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)
5:53 p.m.
On 10/25/2012 05:49 PM, Jannis Achstetter wrote:
Am 25.10.2012 17:23, schrieb Robin Gareus:
it was a thinko anyway.
if (_state < WAIT) return 0;
a few lines later would have caught that condition, too.
On 10/25/2012 04:54 PM, Jannis Achstetter wrote:
Sounds reasonable but still crashes with the same error. I'll try to
debug this further :)
[...]
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) 
5:51 p.m.
On Thu, Oct 25, 2012 at 05:23:28PM +0200, Robin Gareus wrote:
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:
The code to do that is already present: jackclient:cc line 311.
There must be some other problem.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
6:52 p.m.
Am 25.10.2012 17:51, schrieb Fons Adriaensen:
On Thu, Oct 25, 2012 at 05:23:28PM +0200, Robin Gareus
wrote:
valgrind's output is here: http://dpaste.com/hold/818241/
when running in the debugger, one can see the input buffer full of 0x00s
(as floats). Should be okay since we are not connected via JACK to anything.
Jannis
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:
The code to do that is already present: jackclient:cc line 311.
There must be some other problem.
7:37 p.m.
Am 25.10.2012 17:51, schrieb Fons Adriaensen:
On Thu, Oct 25, 2012 at 05:23:28PM +0200, Robin Gareus
wrote:
In my last mail I forgot: zresample works perfectly fine on the files
and with the rates I tried. Output sounds okay, too. However, I don't
know if that uses the same code-paths as the ajbridge.
I tried zita-a2j (the other way round) and the result is about the same:
kripton@miramis ~/audio/zita-resampler-1.2.0/libs $ gdb zita-a2j
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-a2j...done.
(gdb) r -d hw:UA101 -v
Starting program: /usr/bin/zita-a2j -d hw:UA101 -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 : not enabled
capture :
nchan : 12
fsamp : 48000
fsize : 256
nfrag : 2
format : S32_LE
[New Thread 0x7ffff7f9f700 (LWP 6173)]
[New Thread 0x7ffff7f1e700 (LWP 6174)]
[New Thread 0x7ffff7e9d700 (LWP 6175)]
[New Thread 0x7ffff7fcc700 (LWP 6176)]
Starting synchronisation.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7e9d700 (LWP 6175)]
0x00007ffff7bd8760 in VResampler::process (this=0x626680) at
vresampler.cc:217
217 _c2 [i] = a * q2 [i] + b * q2 [i - hl];
(gdb) bt
#0 0x00007ffff7bd8760 in VResampler::process (this=0x626680) at
vresampler.cc:217
#1 0x0000000000403a21 in Jackclient::capture (this=0x6263b0,
nframes=256) at jackclient.cc:245
#2 0x00000000004043a5 in Jackclient::jack_process (this=0x6263b0,
nframes=256) at jackclient.cc:470
#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
Jannis
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:
The code to do that is already present: jackclient:cc line 311.
There must be some other problem.
10:57 p.m.
On Thu, Oct 25, 2012 at 07:37:24PM +0200, Jannis Achstetter wrote:
In my last mail I forgot: zresample works perfectly
fine on the files
and with the rates I tried. Output sounds okay, too. However, I don't
know if that uses the same code-paths as the ajbridge.
Yes and no. The zresample app uses the Resampler class,
while zita-ajbridge uses VResampler. The two share some
code, but they are different classes. Could you try the
zretune app that comes with the latest release of zita-
resamper ? This is using the VResampler class.
warning: Could not load shared library symbols for
linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
I've no idea what linux-vdso.so is ...
This may be unrelated, but I also see frequent errors on
the ALSA device in the valgrind output. Could you test
the device with the alsa_loopback app that comes with
zita-alsa-pcmi, using the same parameters as you'd use
for zita-a2j ?
I suspect this is some 64-bit related problem...
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:37 p.m.
Am 25.10.2012 22:57, schrieb Fons Adriaensen:
Ya, nevermind it, that's always printed but gdb does its job for
backtraces :)
On Thu, Oct 25, 2012 at 07:37:24PM +0200, Jannis
Achstetter wrote:
Okay, the different classes explain the different behavoirs then because
zretune crashes instantly:
(gdb) r --cent 20 test-orig.wav out.wav
Starting program: /usr/bin/zretune --cent 20 test-orig.wav out.wav
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd8760 in VResampler::process (this=0x7fffffffcf50) at
vresampler.cc:217
217 vresampler.cc: No such file or directory.
(gdb) q
In my last mail I forgot: zresample works
perfectly fine on the files
and with the rates I tried. Output sounds okay, too. However, I don't
know if that uses the same code-paths as the ajbridge.
Yes and no. The zresample app uses the Resampler class,
while zita-ajbridge uses VResampler. The two share some
code, but they are different classes. Could you try the
zretune app that comes with the latest release of zita-
resamper ? This is using the VResampler class. warning: Could not load shared library symbols
for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
I've no idea what linux-vdso.so is ... This may be unrelated, but I also see frequent errors
on
the ALSA device in the valgrind output. Could you test
the device with the alsa_loopback app that comes with
zita-alsa-pcmi, using the same parameters as you'd use
for zita-a2j ?
I suspect this is some 64-bit related problem...
I saw the ALSA-errors, too but can't test it right now since I currently
only have the library-part of zita-alsa-pcmi installed. Will install the
other binaries tomorrow and test it then. I can do tests on a pure
32-bit machine if it helps.
Thanks for the help up to now :)
Jannis
26 Oct
26 Oct
9:37 a.m.
On Thu, Oct 25, 2012 at 11:37:30PM +0200, Jannis Achstetter wrote:
Okay, the different classes explain the different
behavoirs then because
zretune crashes instantly:
If you install libzita-resampler from source, try this:
int VResampler::process (void)
{
- unsigned int k, hl, np, in, nr, nz, i, n, c;
+ unsigned int k, np, in, nr, n, c;
+ int i, hl, nz;
double ph, dp, dd;
float a, b, *p1, *p2, *q1, *q2;
In line 217 the index [i - hl] goes negative. If it is extended
to 64 bit as unsigned that would explain the segfault.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
9:59 a.m.
On Fri, Oct 26, 2012 at 07:37:42AM +0000, Fons Adriaensen wrote:
On Thu, Oct 25, 2012 at 11:37:30PM +0200, Jannis
Achstetter wrote:
P.S. To make sure you replace the library installed by your
package manager, you need to change PREFIX at the top of the
Makefile to
PREFIX=/usr
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Okay, the different classes explain the different
behavoirs then because
zretune crashes instantly:
If you install libzita-resampler from source, try this:
int VResampler::process (void)
{
- unsigned int k, hl, np, in, nr, nz, i, n, c;
+ unsigned int k, np, in, nr, n, c;
+ int i, hl, nz;
double ph, dp, dd;
float a, b, *p1, *p2, *q1, *q2;
In line 217 the index [i - hl] goes negative. If it is extended
to 64 bit as unsigned that would explain the segfault.
Ciao,
12:27 p.m.
Am 26.10.2012 09:37, schrieb Fons Adriaensen:
On Thu, Oct 25, 2012 at 11:37:30PM +0200, Jannis
Achstetter wrote:
That patch indeed fixes the problem and
zita-j2a works like a charm now. Nice :) And as expected it uses less
CPU than alsa_in and alsa_out.
I tried alsa_loopback from zita-alsa-pcmi this morning (as
"./alsa_loopback hw:1 hw:1 48000 2048 10"). No errors, no crashes, but
no output on the soundcard. Last line printed is "synced". However, the
documentation is sparse so I didn't know what all these parameters are
for and guessed most of them.
The ajbridge has the same problem. There's the quality-parameter that
defaults to "48" but that's all I get to know about it. No value range,
no indication whether 0 is better or worse than 1000. You could add some
hints to the readme ;)
But thanks for all your work you contribute to linux-audio and your
support :)
Jannis
Okay, the different classes explain the different
behavoirs then because
zretune crashes instantly:
If you install libzita-resampler from source, try this:
int VResampler::process (void)
{
- unsigned int k, hl, np, in, nr, nz, i, n, c;
+ unsigned int k, np, in, nr, n, c;
+ int i, hl, nz;
double ph, dp, dd;
In line 217 the index [i - hl] goes negative. If it is extended
to 64 bit as unsigned that would explain the segfault.
1:57 p.m.
On Fri, Oct 26, 2012 at 12:27:32PM +0200, Jannis Achstetter wrote:
I tried alsa_loopback from zita-alsa-pcmi this morning
(as
"./alsa_loopback hw:1 hw:1 48000 2048 10"). No errors, no crashes, but
no output on the soundcard. Last line printed is "synced". However, the
documentation is sparse so I didn't know what all these parameters are
for and guessed most of them.
It's just a little app to show the API to programmers, and to test
if a soundcard works with the library. It just loops back the first
two inputs to the first two outputs.
The ajbridge has the same problem. There's the
quality-parameter that
defaults to "48" but that's all I get to know about it. No value range,
no indication whether 0 is better or worse than 1000. You could add some
hints to the readme ;)
Will do.
The 'quality' parameter has a range of 16 to 96, it sets the length of
the multiphase filter used for resampling, 48 will be OK in most cases.
CPU load by the resampler is roughly proportional to this value. Full
story in zita-resampler/docs/index.html.
Ciao
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
27 Oct
27 Oct
8:23 p.m.
Am 26.10.2012 13:57, schrieb Fons Adriaensen:
On Fri, Oct 26, 2012 at 12:27:32PM +0200, Jannis
Achstetter wrote:
The 'quality' parameter has a range of 16 to 96, it sets the length of
the multiphase filter used for resampling, 48 will be OK in most cases.
CPU load by the resampler is roughly proportional to this value. Full
story in zita-resampler/docs/index.html.
I had a really nice read on this one, thanks :)
Release 1.3.0 tested and verified to fix the issue. Good to go now.
Jannis
4453
days inactive
4455
days old
linux-audio-user@lists.linuxaudio.org
13 comments
3 participants
participants (3)
-
Fons Adriaensen -
Jannis Achstetter -
Robin Gareus