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)