From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: alsa pcm jack plugin Date: Tue, 10 Jan 2006 18:23:35 +0100 Message-ID: References: <20060108204454.511ad978@mango.fruits.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20060108204454.511ad978@mango.fruits.de> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click