19 Mar
2012
19 Mar
'12
8:51 p.m.
On Mon, Mar 19, 2012 at 06:58:29PM +0100, Robin Gareus wrote:
# mplayer -ao alsa,device=hw=1,0 some_music.wav
# zita-a2j -dhw:1,1
I get endless messages:
Starting synchronisation.
Detected excessive timing errors, waiting 15 seconds.
This may happen with current Jack1 after freewheeling.
(meanwhile I'm back home, the loopback device is hw:3 here)
[terminal 1]
fons@zita1:/audio/audiofiles/tracks> mplayer -ao alsa:device=hw=3.1
diana-krall-almost-blue-44.wav
MPlayer SVN-r34426-4.6.2 (C) 2000-2011 MPlayer Team
181 audio & 384 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing diana-krall-almost-blue-44.wav.
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 4.0 (04.0) of 244.0 (04:04.0) 0.1%
...
[terminal 2]
fons@zita1:~> zita-a2j -d hw:3,0 -r 44100
Starting synchronisation
/me makes connections in qjackctl and hears lovely piano intro...
So this just works. I do indeed have to start mplayer first, but
only the first time. After that I can stop and restart mplayer
without problem. This is probably some quirk of the loopback
device. There is no such thing as 'requesting exclusive access'
in the ALSA pcm API - it depends only on the device.
The message is repeated every ~15 sec; and it does not
stop.
Each time a message is printed there's a short very jittery sound (I can
discern the music) but it remains silent for the remaining time.
The silence is intentional - the app waits for the dust to
settle down after it has detected 'impossible' timing info
from either Jack's DLL or from the one tracking the ALSA device.
There was a bug in the loopback device - it returned the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
How do you conduct this test?
I assume that there is no other ALSA-client involved and you use the
loopback in float/32 mode, w/native samplerate.
Zita-a2j and j2a use libzita-alsa-pmci to access ALSA devices.
It uses exactly the same methods as Jack's backend - very early
versions (libclalsadrv 7 years ago) were in fact a C++ copy
of Jack's backend. That means that whatever works with Jack
will work with zita-a2j and j2a or any of my apps using ALSA.
AFAIK Jack doens't run well with dmix/dsnoop either. And anyway
there's no reason to use them with Jack.
To run the delay test (assuming hw:3 is the loopback device):
[Terminal 1]
zita-a2j -d hw:3,0
[Terminal 2]
zita-j2a -d hw:3,1
[Terminal 3]
jack_delay
and make the required connections.
The off-list reply was a typo - back on LAD now.
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)
19 Mar
19 Mar
9:01 p.m.
New subject: First release of zita-ajbridge
On 03/19/2012 08:51 PM, Fons Adriaensen wrote:
[..]
There was a bug in the loopback device - it returned
the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
right. I'm still using snd-aloop from alsa-driver 1.0.23. I will update
and report back.
Keeping LAD in CC - from my 2nd email:
[..]
So this just works. I do indeed have to start mplayer
first, but
only the first time.
It's because zita-alsa-pcmi.cc first tries float and only uses
SND_PCM_FORMAT_S16_LE as a fallback. I found a solution for this: use
dmix/dsnoop devices for the playback clients but connect zita-?2?
directly to the hw:Loopback,[12].
best,
robin
9:10 p.m.
New subject: First release of zita-ajbridge
On Mon, Mar 19, 2012 at 09:01:41PM +0100, Robin Gareus wrote:
It's because zita-alsa-pcmi.cc first tries float
and only uses
SND_PCM_FORMAT_S16_LE as a fallback. I found a solution for this: use
dmix/dsnoop devices for the playback clients but connect zita-?2?
directly to the hw:Loopback,[12].
Aha. So maybe I should add a 'force-16-bit' option in
zita-alsa-pcmi...
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)
20 Mar
20 Mar
1:09 a.m.
New subject: First release of zita-ajbridge
On 03/19/2012 09:10 PM, Fons Adriaensen wrote:
On Mon, Mar 19, 2012 at 09:01:41PM +0100, Robin Gareus
wrote:
Yes, that'd be welcome. ..and expose it as parameter in zita-ajbridge
(e.g. -f S16).
Also an option to allow setting the jack-client name (e.g. -j myname)
would be great. Last but not least, "inp-*" and "outp-*" ports should
be
named "playback_*" and "capture_*" alike the system:* ports.
@list-lurkers: we've tracked down the sync/silence problem that I am
(was) experiencing. zita-a2j/j2a work just fine with all JACK period
sizes < 1024 (that is 16,..,512); Fons is looking into a fix for that.
Yet another great zita tool in the making. Kudos, Fons.
Cheers!
robin
It's because zita-alsa-pcmi.cc first tries
float and only uses
SND_PCM_FORMAT_S16_LE as a fallback.
Aha. So maybe I should add a 'force-16-bit' option in
zita-alsa-pcmi...
1:06 p.m.
New subject: First release of zita-ajbridge
On Tue, Mar 20, 2012 at 9:09 AM, Robin Gareus <robin(a)gareus.org> wrote:
@list-lurkers: we've tracked down the sync/silence problem that I am
(was) experiencing. zita-a2j/j2a work just fine with all JACK period
sizes < 1024 (that is 16,..,512); Fons is looking into a fix for that.
Yet another great zita tool in the making. Kudos, Fons.
Indeed these look like great tools. However, is the sync/silence problem
fixed in the bugfix release? Running the 0.1.1 release under Arch with
jack2-dbus-ladish 1.9.8-3 still produces the same result for me - endlessly
repeating "Starting synchronisation" message with no audio. This is from
issuing the following command:
zita-j2a -d hw:SB
where hw:SB is a HDA-intel device. Running alsa_out on the same device
works fine.
-michael
1:17 p.m.
New subject: First release of zita-ajbridge
On Tue, Mar 20, 2012 at 09:06:20PM +0900, michael noble wrote:
On Tue, Mar 20, 2012 at 9:09 AM, Robin Gareus
<robin(a)gareus.org> wrote:
There is still a bug that makes the loop filter unstable if Jack's
period size is 1024 or more. It's already fixed and being tested
here, and you can expect and update soon, but meanwhile you should
have Jack's -p < 1024.
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)
@list-lurkers: we've tracked down the sync/silence problem that I am
(was) experiencing. zita-a2j/j2a work just fine with all JACK period
sizes < 1024 (that is 16,..,512); Fons is looking into a fix for that.
Yet another great zita tool in the making. Kudos, Fons.
Indeed these look like great tools. However, is the sync/silence problem
fixed in the bugfix release? Running the 0.1.1 release under Arch with
jack2-dbus-ladish 1.9.8-3 still produces the same result for me - endlessly
repeating "Starting synchronisation" message with no audio. This is from
issuing the following command:
zita-j2a -d hw:SB
where hw:SB is a HDA-intel device. Running alsa_out on the same device
works fine.
1:33 p.m.
New subject: First release of zita-ajbridge
On Tue, Mar 20, 2012 at 9:17 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
There is still a bug that makes the loop filter unstable if Jack's
period size is 1024 or more. It's already fixed and being tested
here, and you can expect and update soon, but meanwhile you should
have Jack's -p < 1024.
Running with a period size of 256 here and still not getting output. Is
there something else I can do tell track down why I'm not getting any
output?
1:36 p.m.
New subject: First release of zita-ajbridge
On 03/20/2012 01:33 PM, michael noble wrote:
On Tue, Mar 20, 2012 at 9:17 PM, Fons Adriaensen
<fons(a)linuxaudio.org>wrote;wrote:
Apply attached patch, and sent the output to Fons :)
robin
There is still a bug that makes the loop filter unstable if Jack's
period size is 1024 or more. It's already fixed and being tested
here, and you can expect and update soon, but meanwhile you should
have Jack's -p < 1024.
Running with a period size of 256 here and still not getting output. Is
there something else I can do tell track down why I'm not getting any
output?
19 Mar
19 Mar
9:05 p.m.
New subject: First release of zita-ajbridge
On Mon, Mar 19, 2012 at 07:51:43PM +0000, Fons Adriaensen wrote:
There was a bug in the loopback device - it returned
the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
Sorry for the confusion, but this is wrong. That bug was in
the jack plugin, not the loop device.
--
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)
10:53 p.m.
New subject: First release of zita-ajbridge
On 03/19/2012 09:05 PM, Fons Adriaensen wrote:
On Mon, Mar 19, 2012 at 07:51:43PM +0000, Fons
Adriaensen wrote:
it does not make a difference. even with mod-aloop from
alsa-driver-1.0.25 I only get "Detected excessive timing errors." errors
and no sound.
It's not a loopback issue. The same problem exists if I use j2a/a2j to
connect a real device.
I just tried both ways: jackd using a USB-device and j2a/aj2 adding a
HDA-intel, as well as vice-versa. Same problem (no sound endless sync
messages) with jackd 0.121.4 AND jackdmp 1.9.8.
zita-ajbridge was compiled with g++-4.6.2 i386.
robin
There was a bug in the loopback device - it
returned the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
Sorry for the confusion, but this is wrong. That bug was in
the jack plugin, not the loop device.
20 Mar
20 Mar
10:08 a.m.
New subject: First release of zita-ajbridge
On 19/03/12 20:51, Fons Adriaensen wrote:
[...]
(meanwhile I'm back home, the loopback device is
hw:3 here)
[terminal 1]
fons@zita1:/audio/audiofiles/tracks> mplayer -ao alsa:device=hw=3.1
diana-krall-almost-blue-44.wav
[...]
[terminal 2]
fons@zita1:~> zita-a2j -d hw:3,0 -r 44100
Starting synchronisation
/me makes connections in qjackctl and hears lovely piano intro...
[...]
If I understood everything correctly you *still* need to set up your
.asoundrc with the jack plugin to have this working right?
Lorenzo.
10:31 a.m.
New subject: First release of zita-ajbridge
On 03/20/2012 10:08 AM, Lorenzo Sutton wrote:
On 19/03/12 20:51, Fons Adriaensen wrote:
[...]
~/.asoundrc: yes[1], jack-plugin:no
http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge
you use the alsa loopback-device instead of the jack-plugin.
Since the "snd-loop" kernel-module is a fully-fledged alsa-device,
application support is in general much better than with the jack-plugin;
however you will have alsa_in/out (or zita-a2j/j2a) running all the time
to bridge the loopback-device to jack (depending on resampling- quality
and CPU it uses 1-3% CPU and eats up a bit more of a laptop's battery).
best,
robin
[1] the .asoundrc is only used to set the default output to the loopback
and to allow concurrent access of alsa-clients to it. It's not required
(you could configure most alsa-clients to directly output to the
loopback-[sub]devices), but handy.
(meanwhile I'm back home, the loopback device
is hw:3 here)
[terminal 1]
fons@zita1:/audio/audiofiles/tracks> mplayer -ao alsa:device=hw=3.1
diana-krall-almost-blue-44.wav
[...]
[terminal 2]
fons@zita1:~> zita-a2j -d hw:3,0 -r 44100
Starting synchronisation
/me makes connections in qjackctl and hears lovely piano intro...
[...]
If I understood everything correctly you *still* need to set up your
.asoundrc with the jack plugin to have this working right?
4421
days inactive
4422
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
4 participants
participants (4)
-
Fons Adriaensen -
Lorenzo Sutton -
michael noble -
Robin Gareus