Re: alsa pcm jack plugin

Takashi Iwai
2006-01-10T17:23:35Z

At Sun, 8 Jan 2006 20:44:54 +0100,
Florian Schmidt wrote:
>
>
> Please reply to alsa-devel only (it is open to nonsubscribers), i
> crossposted to get the attention of everybody who might be able to shed
> light on this issue [or even be able to fix it].
>
> Hi,
>
> i've seen some reports on #lad (irc.freenode.org) about how the alsa pcm
> jack plugin (pcm_jack from now on) fails to work with some (most)
> applications. The two cases i know about from my own experience are:
>
> - xmms
>
> - ninjam
>
> They fail in slightly different ways though. For reference, you find my
> relevant .asoundrc excerpt at the bottom of this mail.
>
> xmms simlpy doesn't start playback when using the jackplug device (well,
> it seems it wants to, but its clock simply stays at 00:00). Jack seems
> to stay functional though.
>
> With ninjam, it is possible to actually get some audio from it (for
> about 10 seconds), then it goes silent/frozen and jack's watchdog kicks
> it out after the timeout time has expired. And jackd is taken down with
> it, too :(

Any chance to get strace at the stalling position?

> I took a small look at the source code (pasted here:
> http://rafb.net/paste/results/W8tJPa63.html for reference (non permanent
> link)) and i found:
>
> write(jack->fd, buf, 1); /* for polling */
>
> (snd_pcm_jack_process_cb(), line 144 in pcm/jack/pcm_jack.c)
>
> write() is a potentially blocking system call. I don't know the details
> well enough to judge whether this is a problem here.
>
> Besides that write() call there's some alsa_lib calls, too, of which i
> don't know whether they potentially block. Namely:
>
> snd_pcm_area_silence
> snd_pcm_area_copy
> snd_pcm_ioplug_mmap_areas

They are likely innocent, irrelevant with i/o tasks.

> I wonder whether cleanly designed this thing would need to have to use
> an alsa lib calls in the process callback at all. And most of all the
> write() should be avoided, too. Shouldn't all communication with the
> pcm_jack's process callback be done via lockless ringbufffers/condition
> variables?

Maybe. The write() there is used just for a poll notification and
wake-up of the caller of poll. So, basically we don't need even a
buffer, but a single condition variable and a simple sleep/wake-up
mechanism for multi threads.

Takashi