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) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
