Re: [xvoice] Hacking ViaVoice, part 4

Re: [xvoice] Hacking ViaVoice, part 4

[Carlo Wood]

On Sat, Jul 12, 2003 at 02:08:34PM +0200, Carlo Wood wrote:
> Hence, the problem is now reduced to the question:
> Why is snd_pcm_update_hw_ptr_interrupt not called anymore
> after we did run into an xrun?

I added a few more printk's and already I can guess
what is the reason that the 'blackbox' (the rest)
stops calling snd_pcm_update_hw_ptr_interrupt:

Jul 12 15:40:38 ansset kernel: Entering snd_pcm_update_hw_ptr_interrupt
Jul 12 15:40:38 ansset kernel: snd_pcm_update_hw_ptr_interrupt: status->hw_ptr set to 2048
Jul 12 15:40:38 ansset kernel: snd_pcm_capture_avail: boundary = 1073741824, status->hw_ptr = 2048, control->appl_ptr = 1024
Jul 12 15:40:38 ansset kernel: Leaving snd_pcm_update_hw_ptr_interrupt with EPIPE

Lets have a closer look at snd_pcm_update_hw_ptr_interrupt:

        runtime->status->hw_ptr = new_hw_ptr;
        printk("snd_pcm_update_hw_ptr_interrupt: status->hw_ptr set to %li\n", runtime->status->hw_ptr);
        runtime->hw_ptr_interrupt = new_hw_ptr - new_hw_ptr % runtime->period_size;

        if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
                avail = snd_pcm_playback_avail(runtime);
        else
                avail = snd_pcm_capture_avail(runtime);
        if (avail > runtime->avail_max)
                runtime->avail_max = avail;
        if (avail >= runtime->stop_threshold) {
                snd_pcm_stop(substream,
                             runtime->status->state == SNDRV_PCM_STATE_DRAINING ?
                             SNDRV_PCM_STATE_SETUP : SNDRV_PCM_STATE_XRUN);
                printk("Leaving snd_pcm_update_hw_ptr_interrupt with EPIPE\n");
                return -EPIPE;
        }
        if (avail >= runtime->control->avail_min)
                wake_up(&runtime->sleep);
        printk("Leaving snd_pcm_update_hw_ptr_interrupt\n");
        return 0;
}

I thought it was said that an xrun should simply be ignored?

What is the correct way to recover from this, to continue
recording in this case, after the xrun?

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: [xvoice] Hacking ViaVoice, part 4

[Jaroslav Kysela]

On Sat, 12 Jul 2003, Carlo Wood wrote:

> On Sat, Jul 12, 2003 at 02:08:34PM +0200, Carlo Wood wrote:
> > Hence, the problem is now reduced to the question:
> > Why is snd_pcm_update_hw_ptr_interrupt not called anymore
> > after we did run into an xrun?
> 
> I added a few more printk's and already I can guess
> what is the reason that the 'blackbox' (the rest)
> stops calling snd_pcm_update_hw_ptr_interrupt:
> 
> I thought it was said that an xrun should simply be ignored?

Yes, but at another level - in the OSS emulation code.

> What is the correct way to recover from this, to continue
> recording in this case, after the xrun?

Call read() or poll(POLLIN) again. I think that your problem might be that 
poll(POLLIN) does not trigger the input in the current ALSA code. Please, 
try this patch with ViaVoice (the patch is also in the ALSA CVS tree):

Index: pcm_oss.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/oss/pcm_oss.c,v
retrieving revision 1.38
diff -u -r1.38 pcm_oss.c
--- pcm_oss.c	4 Jul 2003 08:49:53 -0000	1.38
+++ pcm_oss.c	12 Jul 2003 18:54:30 -0000
@@ -1990,12 +1990,20 @@
 	}
 	if (csubstream != NULL) {
 		snd_pcm_runtime_t *runtime = csubstream->runtime;
+		enum sndrv_pcm_state ostate;
 		poll_wait(file, &runtime->sleep, wait);
 		snd_pcm_stream_lock_irq(csubstream);
-		if (runtime->status->state != SNDRV_PCM_STATE_RUNNING ||
+		if ((ostate = runtime->status->state) != SNDRV_PCM_STATE_RUNNING ||
 		    snd_pcm_oss_capture_ready(csubstream))
 			mask |= POLLIN | POLLRDNORM;
 		snd_pcm_stream_unlock_irq(csubstream);
+		if (ostate != SNDRV_PCM_STATE_RUNNING && runtime->oss.trigger) {
+			snd_pcm_oss_file_t ofile;
+			memset(&ofile, 0, sizeof(ofile));
+			ofile.streams[SNDRV_PCM_STREAM_CAPTURE] = pcm_oss_file->streams[SNDRV_PCM_STREAM_CAPTURE];
+			runtime->oss.trigger = 0;
+			snd_pcm_oss_set_trigger(&ofile, PCM_ENABLE_INPUT);
+		}
 	}
 
 	return mask;


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: [xvoice] Hacking ViaVoice, part 4

[Carlo Wood]

On Sat, Jul 12, 2003 at 08:56:16PM +0200, Jaroslav Kysela wrote:
> On Sat, 12 Jul 2003, Carlo Wood wrote:
> 
> > On Sat, Jul 12, 2003 at 02:08:34PM +0200, Carlo Wood wrote:
> > > Hence, the problem is now reduced to the question:
> > > Why is snd_pcm_update_hw_ptr_interrupt not called anymore
> > > after we did run into an xrun?
> > 
> > I added a few more printk's and already I can guess
> > what is the reason that the 'blackbox' (the rest)
> > stops calling snd_pcm_update_hw_ptr_interrupt:
> > 
> > I thought it was said that an xrun should simply be ignored?
> 
> Yes, but at another level - in the OSS emulation code.

Well, I traced back to this point from an application
that only uses the OSS interface.

> > What is the correct way to recover from this, to continue
> > recording in this case, after the xrun?
> 
> Call read() or poll(POLLIN) again. I think that your problem might be that 
> poll(POLLIN) does not trigger the input in the current ALSA code. Please, 
> try this patch with ViaVoice (the patch is also in the ALSA CVS tree):

This application (ViaVoice) calls neither poll() nor select().
It only calls read() when the SNDCTL_DSP_GETISPACE ioctl returns
that there are bytes that can be read without blocking.

I applied the patch, but it won't do anything: poll is never called.


Allow me to give a summary of the problem:

An old application that uses the OSS interface opens /dev/dsp
and goes in a loop where it only calls read() when the
SNDCTL_DSP_GETISPACE ioctl reports that there is data to be read.

However, before it actually starts that loop is wastes some cpu
so that the (small) recording buffer runs full (with a Creative
soundblaster Live! that happens after 128 ms).

OSS interface or not, the sound recording causes
`snd_pcm_update_hw_ptr_interrupt' to be called.   And as soon
as the buffer overruns this function calls:

    snd_pcm_stop(substream,
		 runtime->status->state == SNDRV_PCM_STATE_DRAINING ?
		 SNDRV_PCM_STATE_SETUP : SNDRV_PCM_STATE_XRUN);

Stopping the stream.

The application calls ioctl(fd, SNDCTL_DSP_GETISPACE, &info)
which runs that there is 2048 bytes available.  The application
calls read() and reads 1024 bytes; THIS read() DOES NOT CAUSE
THE STREAM TO BE STARTED AGAIN.  Next the application calls
again ioctl(fd, SNDCTL_DSP_GETISPACE, &info), which now returns
1024 bytes, and reads the last 1024 bytes.  Again, this read
does not start the stream again.

If subsequential reads would start the stream again, then
this isn't helpful because the application never calls read()
again as ioctl(fd, SNDCTL_DSP_GETISPACE, &info) returns
zero bytes to be read from then on.

Isn't this a bug in the OSS emulation of ALSA?  The correct
behaviour seems to be that the stream is started again as soon
as there is space in the buffer again, thus after the first 'read()',
or after the second read when at least one fragment of space is
available, or in the very least after the read() that causes
the buffer to be empty.

If not, then it is a bug in ViaVoice - how *should* ViaVoice have
worked to this deadlock?

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: [xvoice] Hacking ViaVoice, part 4

[Carlo Wood]

On Sun, Jul 13, 2003 at 01:05:39AM +0200, Carlo Wood wrote:
> If not, then it is a bug in ViaVoice - how *should* ViaVoice have
> worked to this deadlock?
           ^__ avoid



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1