[LAD] First release of zita-ajbridge

[Fons Adriaensen]

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 at 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 at 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)