11 Jul
2013
11 Jul
'13
3:59 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi all,
(apologies if this is the wrong mailing list, but i'm currently only
subscribed to LAD and not LAU. anyhow:)
i'm having serious troubles using zita-ajbridge with alsa loopback
devices.
my basic requirement is, to allow *any* ALSA-only application to be
"jackified".
i'm on debian, and my current tests are done on i386 resp. x86_64, but
my target platform is armel (wandboard solo, powered by a single-core
ARM cortex-A9)
the basic problem i'm facing is, that i don't get much output.
occasionally i do get output (e.g. with mplayer)
so here's what i did:
# modprobe snd-aloop (with all the default parameters)
which gives me:
$ cat /proc/asound/cards
0 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xf0244000 irq 43
1 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xf0240000 irq 16
2 [Loopback ]: Loopback - Loopback
Loopback 1
$ zita-a2j -v -d hw:Loopback,0 -L
playback : not enabled
capture :
nchan : 2
fsamp : 48000
fsize : 256
nfrag : 2
format : S16_LE
Starting synchronisation.
0.460 0.999864
[...]
on another terminal i do:
$ mplayer -ao alsa:device=hw=Loopback.1 STE48.wav
and after connecting zita-a2j to my system's output, i can hear sound.
cool!
ok, so i stop mplayer, and start some other application e.g. Pd (what
else). hooking it up to the loopback device, i start my testpatch:
silence :-(
ok, so mabye Pd is broken, i try some zita app, e.g. zita_delay (from
libzita-alsa-pcmi)
$ alsa_delay hw:Loopback,0 hw:Loopback,0 48000 1024 2
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
synced
Signal below threshold...
Signal below threshold...
[...]
not very surprisingly, it doesn't detect any input signal (zita-j2a is
not running), but i also don't hear any output signal.
hmm.
stopping jack (which quits zita-a2j), i try a alsa_delay on my soundcard:
$ alsa_delay hw:SB,0 hw:SB,0 48000 1024 2
playback :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
capture :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
synced
2176.341 frames 45.340 ms ??
2176.405 frames 45.342 ms ??
and i hear nice sine-tones.
checking the output of alsa_delay vs that of zita-a2j, i notice that
one uses latter S32_LE whereas the former uses FLOAT_LE.
since i cannot change the format of alsa_delay without recompilation,
i try to match the two formats with zita-a2j, by running:
$ zita-a2j -v -d hw:Loopback,0 -p 1024
$ zita-a2j -v -d hw:Loopback,0 -p 1024
playback : not enabled
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
Starting synchronisation.
3.716 0.999042
2.713 0.998499
[...]
which gives me pretty much the same config as is used with alsa_delay.
re-starting `alsa_delay`: still no sound.
just in case: starting zita-j2a as well:
$ zita-j2a -v -d hw:Loopback,0 -p 1024
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture : not enabled
Starting synchronisation.
-2.919 1.000933
-1.457 1.001286
[...]
and making sure that zita-*2* are jack-connected to system, but still
no luck.
hmm, what is going on here?
currently the *only* application that i can convince to use
zita-ajbridge seems to be mplayer, and only in S16_LE mode.
what are the requirements for an application to use zita-ajbridge?
shouldn't other zita applications (like alsa_delay) automagically
fullfill these requirements through libzita-alsa-pcmi?
do my application either have to support FLOAT_LE or be stuck with
S16_LE/2channels forever?
is there a tutorial out there on how to use zita-ajbridge with snd-aloop?
masdr
IOhannes
11 Jul
11 Jul
5:58 p.m.
On Thu, Jul 11, 2013 at 03:59:09PM +0200, IOhannes m zmoelnig wrote:
The normal way to do that would be the ALSA's pcm.jack device.
In your $HOME/.asoundrc:
pcm.!default {
type plug
slave { pcm "jack" }
}
pcm.jack {
type jack
playback_ports {
0 zita-mu1:in_4.L
1 zita-mu1:in_4.R
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
There are two problems with this:
* The .asoundrc specifies the Jack ports it will connect to
instead of those it creates.
* Not all apps will find the device because
- they don't use the 'default' device, and
- they expect a hw: device, and pcm.jack isn't one.
But it works well with mplayer, firefox, chromium and maybe others.
$ zita-a2j -v -d hw:Loopback,0 -L
...
Did you use
hw:Loopback,1
(i.e. the 'other side' of hw:Loopback,0') for Pd ? Works here, but you
need
-alsaadd hw:Loopback,1
in order to find it in Pd's list of devices (which is utterly broken).
See above.
To run alsa_delay you could try:
zita-a2j -d hw:Loopback,0,0
zita-j2a -d hw:Loopback,0,1
alsa_delay hw:Loopback,1,0 hw:Loopback,1,1 48000 256 2
which works nicely here (after connecting the Jack ports).
Wrong question.
zita-a2j and zita-j2a are *not* ALSA devices to be used by an
application - rather the inverse: they are applications that
use an ALSA device (which should be a hw: one). It's aloop which
presents itselfs as a device, tries to masquerade as a real hw:
device but doesn't exactly behave as one.
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)
15 Jul
15 Jul
1:46 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2013-07-11 17:58, Fons Adriaensen wrote:
yeah i know.
however, i was not interested in the "normal" way, but rather in the
"explicit" way, where i would do everything manually (hoping to build
an asoundrc on top of my experiences with doing it manually)
Did you use
hw:Loopback,1
doh!
this is basically the answer i was looking for.
thanks a lot!
yes, i was aware of that.
but then i also was under the impression that i "had it working" with
alsa_in/alsa_out (though in practice i had some problems doing so when
composing the email, so i silently skipped that part), so i was
assuming that the problem was really with zita-ajbridge. from my
experience with both mplayer/zita-ajbridge (mplayer refusing to write
to the device when not being in S16_LE/2chan mode) and with
v4l2-loopback devices, i assumed/know that sometimes both producer and
consumer must agree on the same format.
anyhow, thanks for your quick answer.
fgamsdr
IOhannes
17 Jul
17 Jul
5:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2013-07-15 13:46, IOhannes m zmoelnig wrote:
so now that it is basically running, i'm having troubles to make it
run on the target hardware.
when running zita-a2j resp. -j2a in verbose mode, i understand that
the 1st number (the "loop error") should be as close to zero as possible.
in practice they are varying wildly betweeen +16 and -10.
how bad is this?
more troubling however, is that whenever i start an alsa application
(e.g. alsa_delay), one or both zita-*2* applications complain with:
Detected excessive timing errors, waiting 15 seconds.
This may happen with current Jack1 after freewheeling.
(btw, i'm using robin's jackd2-1.9.10+nobus+20130114gite4730c6c-NMU1)
after 15 or so seconds the waiting application recovers, only to
hick-up again after some seconds (see end of email).
even while the
i'm running the programs as follows:
jackd -dalsa -dhw:0,0 -r44100 -p1024 -n2
zita-j2a -v -d hw:Loopback,0,1 -c2 -r44100 -Q16 -p2048 -n2
zita-a2j -v -d hw:Loopback,0,0 -c2 -r44100 -Q16 -p2048 -n2
alsa_delay hw:Loopback,1,0 hw:Loopback,1,1 44100 2048 2
uname -a shows:
Linux WandBoard3 3.0.35-wand6.2 #1 SMP PREEMPT Wed Jul 17 10:21:20
CEST 2013 armv7l GNU/Linux
top doesn't show anything unusual:
20 0 4636 2344 2108 S 19.2 0.7 0:51.59 alsa_delay
20 0 86272 80m 79m S 9.1 24.9 0:12.38 zita-j2a
20 0 86272 80m 79m S 6.8 24.9 0:09.94 zita-a2j
20 0 92864 87m 80m S 2.9 27.0 0:05.00 jackd
finally: i'm wondering a bit on how to choose proper values for
period-size and fragement size.
that is: should zita-*a* period/nfrags match those of jack and/or
those of alsa_delay?
fgmasdr
IOhannes
typical output of zita-a2j;
-9.554 1.000058
-0.009 1.000039
-10.560 1.000043
9.244 1.000030
0.138 0.999943
3.434 0.999968
21.940 0.999898
16.323 0.999789
Detected excessive timing errors, waiting 15 seconds.
This may happen with current Jack1 after freewheeling.
Starting synchronisation.
-8.978 1.002152
-12.058 1.004386
-8.960 1.006809
14.445 1.000016
-5.345 1.003726
6.023 1.002011
4.334 0.999910
-7.868 1.003941
13.211 0.998161
-0.939 0.999894
-10.023 1.003701
11.972 0.998262
-4.587 1.000754
-0.417 1.001475
7.652 0.997528
-11.767 1.002691
19.205 1.002144
Detected excessive timing errors, waiting 15 seconds.
This may happen with current Jack1 after freewheeling.
5:29 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2013-07-17 17:21, IOhannes m zmoelnig wrote:
i'm running the programs as follows: jackd -dalsa -dhw:0,0 -r44100
-p1024 -n2
ah, and btw, the audio-device is a no-name USB-soundcard, hooked to
the USB-3 port.
$ lsusb
Bus 001 Device 002: ID 08a8:0016 Andrea Electronics
10:09 p.m.
On Wed, Jul 17, 2013 at 05:21:12PM +0200, IOhannes m zmoelnig wrote:
It's not that bad, it just indicates that there is some timing
jitter. This can happen for a variety of reasons, see below.
You could try playing with the value in jclient.cc, line 437
to avoid this. Note that the delay error value printed by -v
is averaged over 1/4 second, while the one tested is not.
This is really a combination of all possible worst-case scenarios.
* Does your HW have a high resolution timer that Jack can use
for its microseconds timer ? If not there will be trouble.
* Same for the aloop device. It emulates a HW device at some
configured sample rate, and therefore depends on an accurate
timer in order to do this without loads of jitter.
* I have *no* idea of the correct implementation of the DLL used
in Jack2, but zita-ajbridge does critically depend on it.
* For anything USB, 44.1 kHz is really asking for trouble. With
48 kHz you have at least a a simpler relation to the USB interrupt
rate of 1 kHz, and if that doesn't help using -n 3 probably will.
I don't know 'Andrea Electronics'...
* Keep in mind that zita-ajbridge was not designed to be used
this way. Its primary use is to add an additional (decent)
soundcard to Jack, and I have my doubts about aloop.
For Jack vs. zita-*2* there are no restrictions. In normal use
(that is adding a real sound card to Jack), you would make the
period size of zita-*2* shorter than the one used by Jack
(unless that is already quite small) to avoid additional latency.
I don't know how having different period sizes on both ends of
an aloop would affect it.
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 Jul
11 Jul
8:49 p.m.
Le Thu, 11 Jul 2013 15:59:09 +0200,
IOhannes m zmoelnig <zmoelnig(a)iem.at> a écrit :
You can setup /etc/modules.d/alsa.conf, or whatever file used by
Debian to configure the ALSA driver, to define the Loopback as card 0.
That way, all the ALSA program will access the loopback by default.
Of course, jackd must be running all the time for that to be useful.
Dominique
--
"We have the heroes we deserve."
12 Jul
12 Jul
2:52 a.m.
Dominique Michel wrote:
Will pulseaudio accept the loopback device defined
as card 0? It would be nice to have a bone to throw
to pulseaudio. More and more of my distribution's
packages seem to depend on it, including
that for a widely used video-conferencing client.
Joel
Dominique
--
"We have the heroes we deserve."
--
Joel Roth
11:17 p.m.
Le Thu, 11 Jul 2013 14:52:28 -1000,
Joel Roth <joelz(a)pobox.com> a écrit :
I don't know. pulseaudio is not installed into my system. I don't
want polkit, so I removed the whole of gnome :P)
But I think it should work, pulseaudio have both a jack sink that can
output directly to jack, and an alsa sink that can output to alsa.
--
"We have the heroes we deserve."
4281
days inactive
4287
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Dominique Michel -
Fons Adriaensen -
IOhannes m zmoelnig -
Joel Roth