quit snd_pcm_readi, retrieve pending frames

quit snd_pcm_readi, retrieve pending frames

[Gerald Grabner]

Hi,

I'm experimenting with the ALSA PCM API and was wondering whether
there is a simple way to exit a record loop by stopping the pcm, but
without loosing pending frames.

Initially, I was thinking of something like this, where I would call
snd_pcm_drop(pcm) from some other thread:

   while ( true )
     {
       r = snd_pcm_readi (pcm, data, frames);
       fwrite (data, 2, 2*r, file);
       if ( r != frames )
         break;
     }

However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
r=-EBADFD.

Is there an easy way to stop snd_pcm_readi in a way that I can
retrieve the residual frames? Do I need to set any parameters for
that purpose?

Many thanks,
Gerald

BTW: I'm using alsa 1.0.11 on gentoo.


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: quit snd_pcm_readi, retrieve pending frames

[Clemens Ladisch]

Gerald Grabner wrote:
> Is there an easy way to stop snd_pcm_readi in a way that I can
> retrieve the residual frames?

snd_pcm_readi uses only the readiness state of the PCM device to
determine when to unblock.

If you want to wait for another event, use non-blocking mode and add
another handle to poll().  Typically, a pipe is used for this.


HTH
Clemens


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: quit snd_pcm_readi, retrieve pending frames

[Takashi Iwai]

At Sat, 13 May 2006 13:06:51 +0200,
Gerald Grabner wrote:
> 
> Hi,
> 
> I'm experimenting with the ALSA PCM API and was wondering whether
> there is a simple way to exit a record loop by stopping the pcm, but
> without loosing pending frames.
> 
> Initially, I was thinking of something like this, where I would call
> snd_pcm_drop(pcm) from some other thread:
> 
>    while ( true )
>      {
>        r = snd_pcm_readi (pcm, data, frames);
>        fwrite (data, 2, 2*r, file);
>        if ( r != frames )
>          break;
>      }
> 
> However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> r=-EBADFD.
> 
> Is there an easy way to stop snd_pcm_readi in a way that I can
> retrieve the residual frames? Do I need to set any parameters for
> that purpose?

If you're using hw or plughw, it's likely a bug in alsa-driver.
Try the patch below.

dsnoop plugin should work as it is, though, and dsnoop is used for
many drivers as default.  Check your configuration at first.


Takashi


diff -r d1f5192b7abb core/pcm_native.c
--- a/core/pcm_native.c	Thu May 11 18:12:23 2006 +0200
+++ b/core/pcm_native.c	Mon May 15 12:00:27 2006 +0200
@@ -1406,6 +1406,18 @@ struct drain_rec {
 
 static int snd_pcm_drop(struct snd_pcm_substream *substream);
 
+static int pcms_still_draining(struct snd_pcm_substream *substream)
+{
+	struct list_head *pos;
+	snd_pcm_group_for_each(pos, substream) {
+		struct snd_pcm_substream *s;
+		s = snd_pcm_group_substream_entry(pos);
+		if (s->runtime->status->state == SNDRV_PCM_STATE_DRAINING)
+			return 1;
+	}
+	return 0; /* yes, all drained */
+}
+
 /*
  * Drain the stream(s).
  * When the substream is linked, sync until the draining of all playback streams
@@ -1469,8 +1481,6 @@ static int snd_pcm_drain(struct snd_pcm_
 		}
 	}
 	up_read(&snd_pcm_link_rwsem);
-	if (! num_drecs)
-		goto _error;
 
 	snd_pcm_stream_lock_irq(substream);
 	/* resume pause */
@@ -1484,21 +1494,12 @@ static int snd_pcm_drain(struct snd_pcm_
 		goto _error;
 	}
 
-	for (;;) {
+	while (pcms_still_draining(substream)) {
 		long tout;
 		if (signal_pending(current)) {
 			result = -ERESTARTSYS;
 			break;
 		}
-		/* all finished? */
-		for (i = 0; i < num_drecs; i++) {
-			runtime = drec[i].substream->runtime;
-			if (runtime->status->state == SNDRV_PCM_STATE_DRAINING)
-				break;
-		}
-		if (i == num_drecs)
-			break; /* yes, all drained */
-
 		set_current_state(TASK_INTERRUPTIBLE);
 		snd_pcm_stream_unlock_irq(substream);
 		snd_power_unlock(card);


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: quit snd_pcm_readi, retrieve pending frames

[Takashi Iwai]

At Mon, 15 May 2006 12:06:47 +0200,
I wrote:
> 
> At Sat, 13 May 2006 13:06:51 +0200,
> Gerald Grabner wrote:
> > 
> > Hi,
> > 
> > I'm experimenting with the ALSA PCM API and was wondering whether
> > there is a simple way to exit a record loop by stopping the pcm, but
> > without loosing pending frames.
> > 
> > Initially, I was thinking of something like this, where I would call
> > snd_pcm_drop(pcm) from some other thread:
> > 
> >    while ( true )
> >      {
> >        r = snd_pcm_readi (pcm, data, frames);
> >        fwrite (data, 2, 2*r, file);
> >        if ( r != frames )
> >          break;
> >      }
> > 
> > However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> > snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> > r=-EBADFD.
> > 
> > Is there an easy way to stop snd_pcm_readi in a way that I can
> > retrieve the residual frames? Do I need to set any parameters for
> > that purpose?
> 
> If you're using hw or plughw, it's likely a bug in alsa-driver.
> Try the patch below.

Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
the capture streams.  So, the patch becomes pretty simple like below.
I'll commit it to HG repo.


Takashi


diff -r 44d28ed5d3d5 core/pcm_native.c
--- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
+++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
@@ -1469,8 +1469,6 @@ static int snd_pcm_drain(struct snd_pcm_
 		}
 	}
 	up_read(&snd_pcm_link_rwsem);
-	if (! num_drecs)
-		goto _error;
 
 	snd_pcm_stream_lock_irq(substream);
 	/* resume pause */


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: quit snd_pcm_readi, retrieve pending frames

[Gerald Grabner]

Takashi Iwai <tiwai <at> suse.de> writes:
> 
> At Mon, 15 May 2006 12:06:47 +0200,
> I wrote:
> > 
> > At Sat, 13 May 2006 13:06:51 +0200,
> > Gerald Grabner wrote:
> > > 
> > > Hi,
> > > 
> > > I'm experimenting with the ALSA PCM API and was wondering whether
> > > there is a simple way to exit a record loop by stopping the pcm, but
> > > without loosing pending frames.
> > > 
> > > Initially, I was thinking of something like this, where I would call
> > > snd_pcm_drop(pcm) from some other thread:
> > > 
> > >    while ( true )
> > >      {
> > >        r = snd_pcm_readi (pcm, data, frames);
> > >        fwrite (data, 2, 2*r, file);
> > >        if ( r != frames )
> > >          break;
> > >      }
> > > 
> > > However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> > > snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> > > r=-EBADFD.
> > > 
> > > Is there an easy way to stop snd_pcm_readi in a way that I can
> > > retrieve the residual frames? Do I need to set any parameters for
> > > that purpose?
> > 
> > If you're using hw or plughw, it's likely a bug in alsa-driver.
> > Try the patch below.
> 
> Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
> the capture streams.  So, the patch becomes pretty simple like below.
> I'll commit it to HG repo.
> 
> Takashi
> 
> diff -r 44d28ed5d3d5 core/pcm_native.c
> --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
> +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
>  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
struct snd_pcm_
>  		}
>  	}
>  	up_read(&snd_pcm_link_rwsem);
> -	if (! num_drecs)
> -		goto _error;
> 
>  	snd_pcm_stream_lock_irq(substream);
>  	/* resume pause */


Hi Takashi,

there seems to be some problem with this patch (the short one). After
recompiling the kernel (and my application), my application doesn't
exit and I can't kill it anymore. The pcm device is kind of lost. See
below for the /var/log/messages entry.

Gerald


May 19 22:49:58 tux Unable to handle kernel NULL pointer dereference
at virtual address 00000001
May 19 22:49:58 tux printing eip:
May 19 22:49:58 tux 00000001
May 19 22:49:58 tux *pde = 00000000
May 19 22:49:58 tux Oops: 0000 [#1]
May 19 22:49:58 tux PREEMPT 
May 19 22:49:58 tux Modules linked in: ipt_REJECT xt_tcpudp
iptable_filter ipt_MASQUERADE iptable_nat ip_nat ip_conntrack
ip_tables x_tables nvidia
May 19 22:49:58 tux CPU:    0
May 19 22:49:58 tux EIP:    0060:[<00000001>]    Tainted: P      VLI
May 19 22:49:58 tux EFLAGS: 00210087   (2.6.16-gentoo-r7 #2) 
May 19 22:49:58 tux EIP is at 0x1
May 19 22:49:58 tux eax: d8f83ebc ebx: 00000001 ecx: 00000001 edx:
d8f83ec8
May 19 22:49:58 tux esi: 00000001 edi: db22e4a4 ebp: d87e1e84 esp:
d87e1e60
May 19 22:49:58 tux ds: 007b   es: 007b   ss: 0068
May 19 22:49:58 tux Process mplay (pid: 10349, threadinfo=d87e0000
task=df8f60d0)
May 19 22:49:58 tux Stack: <0>c010f8d4 d8f83ebc 00000003 00000000
00000000 00200002 d87e0000 00000000
May 19 22:49:58 tux 00200046 d87e1eac c010f911 db22e4a4 00000003
00000001 00000000 00000000
May 19 22:49:58 tux 00000000 00000001 c03d12fc dfcad980 c02afde4
00000000 00000001 d87e0000
May 19 22:49:58 tux Call Trace:
May 19 22:49:58 tux [<c010f8d4>] __wake_up_common+0x2b/0x47
May 19 22:49:58 tux [<c010f911>] __wake_up+0x21/0x44
May 19 22:49:58 tux [<c02afde4>] snd_pcm_action_single+0x2e/0x44
May 19 22:49:58 tux [<c02afe45>] snd_pcm_action+0x4b/0x55
May 19 22:49:58 tux [<c02b0118>] snd_pcm_stop+0x12/0x16
May 19 22:49:58 tux [<c02b0bbc>] snd_pcm_drop+0x8b/0xc3
May 19 22:49:58 tux [<c02b19d9>] snd_pcm_release+0x1e/0xbb
May 19 22:49:58 tux [<c01444d1>] __fput+0x83/0x142
May 19 22:49:58 tux [<c0143146>] filp_close+0x4c/0x55
May 19 22:49:58 tux [<c011426d>] close_files+0x4b/0x5b
May 19 22:49:58 tux [<c01142be>] put_files_struct+0x13/0x3b
May 19 22:49:58 tux [<c0114bd7>] do_exit+0x19a/0x35d
May 19 22:49:58 tux [<c0114e4f>] sys_exit_group+0x0/0x11
May 19 22:49:58 tux [<c0102549>] syscall_call+0x7/0xb
May 19 22:49:58 tux Code:  Bad EIP value.
May 19 22:49:58 tux <1>Fixing recursive fault but reboot is needed!
May 19 22:49:58 tux scheduling while atomic: mplay/0x00000003/10349
May 19 22:49:58 tux [<c033cbf1>] schedule+0x43/0x53f
May 19 22:49:58 tux [<c0102773>] error_code+0x4f/0x54
May 19 22:49:58 tux [<c0114aea>] do_exit+0xad/0x35d
May 19 22:49:58 tux [<c0102e2b>] do_trap+0x0/0xc1
May 19 22:49:58 tux [<c010e3c8>] do_page_fault+0x38d/0x4bd
May 19 22:49:58 tux [<c0116b54>] __do_softirq+0x34/0x7d
May 19 22:49:58 tux [<c010e03b>] do_page_fault+0x0/0x4bd
May 19 22:49:58 tux [<c0102773>] error_code+0x4f/0x54
May 19 22:49:58 tux [<c010f8d4>] __wake_up_common+0x2b/0x47
May 19 22:49:58 tux [<c010f911>] __wake_up+0x21/0x44
May 19 22:49:58 tux [<c02afde4>] snd_pcm_action_single+0x2e/0x44
May 19 22:49:58 tux [<c02afe45>] snd_pcm_action+0x4b/0x55
May 19 22:49:58 tux [<c02b0118>] snd_pcm_stop+0x12/0x16
May 19 22:49:58 tux [<c02b0bbc>] snd_pcm_drop+0x8b/0xc3
May 19 22:49:58 tux [<c02b19d9>] snd_pcm_release+0x1e/0xbb
May 19 22:49:58 tux [<c01444d1>] __fput+0x83/0x142
May 19 22:49:58 tux [<c0143146>] filp_close+0x4c/0x55
May 19 22:49:58 tux [<c011426d>] close_files+0x4b/0x5b
May 19 22:49:58 tux [<c01142be>] put_files_struct+0x13/0x3b
May 19 22:49:58 tux [<c0114bd7>] do_exit+0x19a/0x35d
May 19 22:49:58 tux [<c0114e4f>] sys_exit_group+0x0/0x11
May 19 22:49:58 tux [<c0102549>] syscall_call+0x7/0xb




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Re: quit snd_pcm_readi, retrieve pending frames

[Takashi Iwai]

At Fri, 19 May 2006 21:17:45 +0000 (UTC),
Gerald Grabner wrote:
> 
> Takashi Iwai <tiwai <at> suse.de> writes:
> > 
> > At Mon, 15 May 2006 12:06:47 +0200,
> > I wrote:
> > > 
> > > At Sat, 13 May 2006 13:06:51 +0200,
> > > Gerald Grabner wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I'm experimenting with the ALSA PCM API and was wondering whether
> > > > there is a simple way to exit a record loop by stopping the pcm, but
> > > > without loosing pending frames.
> > > > 
> > > > Initially, I was thinking of something like this, where I would call
> > > > snd_pcm_drop(pcm) from some other thread:
> > > > 
> > > >    while ( true )
> > > >      {
> > > >        r = snd_pcm_readi (pcm, data, frames);
> > > >        fwrite (data, 2, 2*r, file);
> > > >        if ( r != frames )
> > > >          break;
> > > >      }
> > > > 
> > > > However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> > > > snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> > > > r=-EBADFD.
> > > > 
> > > > Is there an easy way to stop snd_pcm_readi in a way that I can
> > > > retrieve the residual frames? Do I need to set any parameters for
> > > > that purpose?
> > > 
> > > If you're using hw or plughw, it's likely a bug in alsa-driver.
> > > Try the patch below.
> > 
> > Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
> > the capture streams.  So, the patch becomes pretty simple like below.
> > I'll commit it to HG repo.
> > 
> > Takashi
> > 
> > diff -r 44d28ed5d3d5 core/pcm_native.c
> > --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
> > +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
> >  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
> struct snd_pcm_
> >  		}
> >  	}
> >  	up_read(&snd_pcm_link_rwsem);
> > -	if (! num_drecs)
> > -		goto _error;
> > 
> >  	snd_pcm_stream_lock_irq(substream);
> >  	/* resume pause */
> 
> 
> Hi Takashi,
> 
> there seems to be some problem with this patch (the short one). After
> recompiling the kernel (and my application), my application doesn't
> exit and I can't kill it anymore. The pcm device is kind of lost. See
> below for the /var/log/messages entry.

Hmm, according the error message below, I suspect it's something
different since the patch isn't so intrusive.

Could you test again after reverting the patched part?


thanks,

Takashi

> 
> Gerald
> 
> 
> May 19 22:49:58 tux Unable to handle kernel NULL pointer dereference
> at virtual address 00000001
> May 19 22:49:58 tux printing eip:
> May 19 22:49:58 tux 00000001
> May 19 22:49:58 tux *pde = 00000000
> May 19 22:49:58 tux Oops: 0000 [#1]
> May 19 22:49:58 tux PREEMPT 
> May 19 22:49:58 tux Modules linked in: ipt_REJECT xt_tcpudp
> iptable_filter ipt_MASQUERADE iptable_nat ip_nat ip_conntrack
> ip_tables x_tables nvidia
> May 19 22:49:58 tux CPU:    0
> May 19 22:49:58 tux EIP:    0060:[<00000001>]    Tainted: P      VLI
> May 19 22:49:58 tux EFLAGS: 00210087   (2.6.16-gentoo-r7 #2) 
> May 19 22:49:58 tux EIP is at 0x1
> May 19 22:49:58 tux eax: d8f83ebc ebx: 00000001 ecx: 00000001 edx:
> d8f83ec8
> May 19 22:49:58 tux esi: 00000001 edi: db22e4a4 ebp: d87e1e84 esp:
> d87e1e60
> May 19 22:49:58 tux ds: 007b   es: 007b   ss: 0068
> May 19 22:49:58 tux Process mplay (pid: 10349, threadinfo=d87e0000
> task=df8f60d0)
> May 19 22:49:58 tux Stack: <0>c010f8d4 d8f83ebc 00000003 00000000
> 00000000 00200002 d87e0000 00000000
> May 19 22:49:58 tux 00200046 d87e1eac c010f911 db22e4a4 00000003
> 00000001 00000000 00000000
> May 19 22:49:58 tux 00000000 00000001 c03d12fc dfcad980 c02afde4
> 00000000 00000001 d87e0000
> May 19 22:49:58 tux Call Trace:
> May 19 22:49:58 tux [<c010f8d4>] __wake_up_common+0x2b/0x47
> May 19 22:49:58 tux [<c010f911>] __wake_up+0x21/0x44
> May 19 22:49:58 tux [<c02afde4>] snd_pcm_action_single+0x2e/0x44
> May 19 22:49:58 tux [<c02afe45>] snd_pcm_action+0x4b/0x55
> May 19 22:49:58 tux [<c02b0118>] snd_pcm_stop+0x12/0x16
> May 19 22:49:58 tux [<c02b0bbc>] snd_pcm_drop+0x8b/0xc3
> May 19 22:49:58 tux [<c02b19d9>] snd_pcm_release+0x1e/0xbb
> May 19 22:49:58 tux [<c01444d1>] __fput+0x83/0x142
> May 19 22:49:58 tux [<c0143146>] filp_close+0x4c/0x55
> May 19 22:49:58 tux [<c011426d>] close_files+0x4b/0x5b
> May 19 22:49:58 tux [<c01142be>] put_files_struct+0x13/0x3b
> May 19 22:49:58 tux [<c0114bd7>] do_exit+0x19a/0x35d
> May 19 22:49:58 tux [<c0114e4f>] sys_exit_group+0x0/0x11
> May 19 22:49:58 tux [<c0102549>] syscall_call+0x7/0xb
> May 19 22:49:58 tux Code:  Bad EIP value.
> May 19 22:49:58 tux <1>Fixing recursive fault but reboot is needed!
> May 19 22:49:58 tux scheduling while atomic: mplay/0x00000003/10349
> May 19 22:49:58 tux [<c033cbf1>] schedule+0x43/0x53f
> May 19 22:49:58 tux [<c0102773>] error_code+0x4f/0x54
> May 19 22:49:58 tux [<c0114aea>] do_exit+0xad/0x35d
> May 19 22:49:58 tux [<c0102e2b>] do_trap+0x0/0xc1
> May 19 22:49:58 tux [<c010e3c8>] do_page_fault+0x38d/0x4bd
> May 19 22:49:58 tux [<c0116b54>] __do_softirq+0x34/0x7d
> May 19 22:49:58 tux [<c010e03b>] do_page_fault+0x0/0x4bd
> May 19 22:49:58 tux [<c0102773>] error_code+0x4f/0x54
> May 19 22:49:58 tux [<c010f8d4>] __wake_up_common+0x2b/0x47
> May 19 22:49:58 tux [<c010f911>] __wake_up+0x21/0x44
> May 19 22:49:58 tux [<c02afde4>] snd_pcm_action_single+0x2e/0x44
> May 19 22:49:58 tux [<c02afe45>] snd_pcm_action+0x4b/0x55
> May 19 22:49:58 tux [<c02b0118>] snd_pcm_stop+0x12/0x16
> May 19 22:49:58 tux [<c02b0bbc>] snd_pcm_drop+0x8b/0xc3
> May 19 22:49:58 tux [<c02b19d9>] snd_pcm_release+0x1e/0xbb
> May 19 22:49:58 tux [<c01444d1>] __fput+0x83/0x142
> May 19 22:49:58 tux [<c0143146>] filp_close+0x4c/0x55
> May 19 22:49:58 tux [<c011426d>] close_files+0x4b/0x5b
> May 19 22:49:58 tux [<c01142be>] put_files_struct+0x13/0x3b
> May 19 22:49:58 tux [<c0114bd7>] do_exit+0x19a/0x35d
> May 19 22:49:58 tux [<c0114e4f>] sys_exit_group+0x0/0x11
> May 19 22:49:58 tux [<c0102549>] syscall_call+0x7/0xb
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Re: quit snd_pcm_readi, retrieve pending frames

[Gerald Grabner]

Takashi Iwai wrote:
> At Fri, 19 May 2006 21:17:45 +0000 (UTC),
> Gerald Grabner wrote:
>> Takashi Iwai <tiwai <at> suse.de> writes:
>>> At Mon, 15 May 2006 12:06:47 +0200,
>>> I wrote:
>>>> At Sat, 13 May 2006 13:06:51 +0200,
>>>> Gerald Grabner wrote:
>>>>> Hi,
>>>>>
>>>>> I'm experimenting with the ALSA PCM API and was wondering whether
>>>>> there is a simple way to exit a record loop by stopping the pcm, but
>>>>> without loosing pending frames.
>>>>>
>>>>> Initially, I was thinking of something like this, where I would call
>>>>> snd_pcm_drop(pcm) from some other thread:
>>>>>
>>>>>    while ( true )
>>>>>      {
>>>>>        r = snd_pcm_readi (pcm, data, frames);
>>>>>        fwrite (data, 2, 2*r, file);
>>>>>        if ( r != frames )
>>>>>          break;
>>>>>      }
>>>>>
>>>>> However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
>>>>> snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
>>>>> r=-EBADFD.
>>>>>
>>>>> Is there an easy way to stop snd_pcm_readi in a way that I can
>>>>> retrieve the residual frames? Do I need to set any parameters for
>>>>> that purpose?
>>>> If you're using hw or plughw, it's likely a bug in alsa-driver.
>>>> Try the patch below.
>>> Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
>>> the capture streams.  So, the patch becomes pretty simple like below.
>>> I'll commit it to HG repo.
>>>
>>> Takashi
>>>
>>> diff -r 44d28ed5d3d5 core/pcm_native.c
>>> --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
>>> +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
>>>  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
>> struct snd_pcm_
>>>  		}
>>>  	}
>>>  	up_read(&snd_pcm_link_rwsem);
>>> -	if (! num_drecs)
>>> -		goto _error;
>>>
>>>  	snd_pcm_stream_lock_irq(substream);
>>>  	/* resume pause */
>>
>> Hi Takashi,
>>
>> there seems to be some problem with this patch (the short one). After
>> recompiling the kernel (and my application), my application doesn't
>> exit and I can't kill it anymore. The pcm device is kind of lost. See
>> below for the /var/log/messages entry.
> 
> Hmm, according the error message below, I suspect it's something
> different since the patch isn't so intrusive.
> 
> Could you test again after reverting the patched part?

After recompiling the kernel with the original source, the problem
disappeared.

Gerald


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Re: quit snd_pcm_readi, retrieve pending frames

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

At Sat, 20 May 2006 20:46:34 +0200,
Gerald Grabner wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 19 May 2006 21:17:45 +0000 (UTC),
> > Gerald Grabner wrote:
> >> Takashi Iwai <tiwai <at> suse.de> writes:
> >>> At Mon, 15 May 2006 12:06:47 +0200,
> >>> I wrote:
> >>>> At Sat, 13 May 2006 13:06:51 +0200,
> >>>> Gerald Grabner wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'm experimenting with the ALSA PCM API and was wondering whether
> >>>>> there is a simple way to exit a record loop by stopping the pcm, but
> >>>>> without loosing pending frames.
> >>>>>
> >>>>> Initially, I was thinking of something like this, where I would call
> >>>>> snd_pcm_drop(pcm) from some other thread:
> >>>>>
> >>>>>    while ( true )
> >>>>>      {
> >>>>>        r = snd_pcm_readi (pcm, data, frames);
> >>>>>        fwrite (data, 2, 2*r, file);
> >>>>>        if ( r != frames )
> >>>>>          break;
> >>>>>      }
> >>>>>
> >>>>> However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> >>>>> snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> >>>>> r=-EBADFD.
> >>>>>
> >>>>> Is there an easy way to stop snd_pcm_readi in a way that I can
> >>>>> retrieve the residual frames? Do I need to set any parameters for
> >>>>> that purpose?
> >>>> If you're using hw or plughw, it's likely a bug in alsa-driver.
> >>>> Try the patch below.
> >>> Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
> >>> the capture streams.  So, the patch becomes pretty simple like below.
> >>> I'll commit it to HG repo.
> >>>
> >>> Takashi
> >>>
> >>> diff -r 44d28ed5d3d5 core/pcm_native.c
> >>> --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
> >>> +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
> >>>  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
> >> struct snd_pcm_
> >>>  		}
> >>>  	}
> >>>  	up_read(&snd_pcm_link_rwsem);
> >>> -	if (! num_drecs)
> >>> -		goto _error;
> >>>
> >>>  	snd_pcm_stream_lock_irq(substream);
> >>>  	/* resume pause */
> >>
> >> Hi Takashi,
> >>
> >> there seems to be some problem with this patch (the short one). After
> >> recompiling the kernel (and my application), my application doesn't
> >> exit and I can't kill it anymore. The pcm device is kind of lost. See
> >> below for the /var/log/messages entry.
> > 
> > Hmm, according the error message below, I suspect it's something
> > different since the patch isn't so intrusive.
> > 
> > Could you test again after reverting the patched part?
> 
> After recompiling the kernel with the original source, the problem
> disappeared.

OK, could you try the patch below?


thanks,

Takashi

[-- Attachment #2: Type: text/plain, Size: 540 bytes --]

diff -r 18da48cda4cc core/pcm_native.c
--- a/core/pcm_native.c	Mon May 22 12:05:42 2006 +0200
+++ b/core/pcm_native.c	Mon May 22 12:39:22 2006 +0200
@@ -1381,7 +1381,8 @@ static int snd_pcm_do_drain_init(struct 
 		if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) {
 			int state = snd_pcm_capture_avail(runtime) > 0 ?
 				SNDRV_PCM_STATE_DRAINING : SNDRV_PCM_STATE_SETUP;
-			snd_pcm_do_stop(substream, state);
+			substream->ops->trigger(substream,
+						SNDRV_PCM_TRIGGER_STOP);
 			snd_pcm_post_stop(substream, state);
 		}
 	}

Re: Re: quit snd_pcm_readi, retrieve pending frames

[Takashi Iwai]

At Mon, 22 May 2006 12:41:45 +0200,
I wrote:
> 
> [1  <text/plain; US-ASCII (7bit)>]
> At Sat, 20 May 2006 20:46:34 +0200,
> Gerald Grabner wrote:
> > 
> > Takashi Iwai wrote:
> > > At Fri, 19 May 2006 21:17:45 +0000 (UTC),
> > > Gerald Grabner wrote:
> > >> Takashi Iwai <tiwai <at> suse.de> writes:
> > >>> At Mon, 15 May 2006 12:06:47 +0200,
> > >>> I wrote:
> > >>>> At Sat, 13 May 2006 13:06:51 +0200,
> > >>>> Gerald Grabner wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I'm experimenting with the ALSA PCM API and was wondering whether
> > >>>>> there is a simple way to exit a record loop by stopping the pcm, but
> > >>>>> without loosing pending frames.
> > >>>>>
> > >>>>> Initially, I was thinking of something like this, where I would call
> > >>>>> snd_pcm_drop(pcm) from some other thread:
> > >>>>>
> > >>>>>    while ( true )
> > >>>>>      {
> > >>>>>        r = snd_pcm_readi (pcm, data, frames);
> > >>>>>        fwrite (data, 2, 2*r, file);
> > >>>>>        if ( r != frames )
> > >>>>>          break;
> > >>>>>      }
> > >>>>>
> > >>>>> However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
> > >>>>> snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
> > >>>>> r=-EBADFD.
> > >>>>>
> > >>>>> Is there an easy way to stop snd_pcm_readi in a way that I can
> > >>>>> retrieve the residual frames? Do I need to set any parameters for
> > >>>>> that purpose?
> > >>>> If you're using hw or plughw, it's likely a bug in alsa-driver.
> > >>>> Try the patch below.
> > >>> Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
> > >>> the capture streams.  So, the patch becomes pretty simple like below.
> > >>> I'll commit it to HG repo.
> > >>>
> > >>> Takashi
> > >>>
> > >>> diff -r 44d28ed5d3d5 core/pcm_native.c
> > >>> --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
> > >>> +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
> > >>>  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
> > >> struct snd_pcm_
> > >>>  		}
> > >>>  	}
> > >>>  	up_read(&snd_pcm_link_rwsem);
> > >>> -	if (! num_drecs)
> > >>> -		goto _error;
> > >>>
> > >>>  	snd_pcm_stream_lock_irq(substream);
> > >>>  	/* resume pause */
> > >>
> > >> Hi Takashi,
> > >>
> > >> there seems to be some problem with this patch (the short one). After
> > >> recompiling the kernel (and my application), my application doesn't
> > >> exit and I can't kill it anymore. The pcm device is kind of lost. See
> > >> below for the /var/log/messages entry.
> > > 
> > > Hmm, according the error message below, I suspect it's something
> > > different since the patch isn't so intrusive.
> > > 
> > > Could you test again after reverting the patched part?
> > 
> > After recompiling the kernel with the original source, the problem
> > disappeared.
> 
> OK, could you try the patch below?

In case it still doesn't fix -- please elaborate what your app
actually does.  Or even better a small test code.
I still don't figure out how can it happen.


thanks,

Takashi


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: quit snd_pcm_readi, retrieve pending frames

[Gerald Grabner]

Takashi Iwai wrote:
> At Sat, 20 May 2006 20:46:34 +0200,
> Gerald Grabner wrote:
>> Takashi Iwai wrote:
>>> At Fri, 19 May 2006 21:17:45 +0000 (UTC),
>>> Gerald Grabner wrote:
>>>> Takashi Iwai <tiwai <at> suse.de> writes:
>>>>> At Mon, 15 May 2006 12:06:47 +0200,
>>>>> I wrote:
>>>>>> At Sat, 13 May 2006 13:06:51 +0200,
>>>>>> Gerald Grabner wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm experimenting with the ALSA PCM API and was wondering whether
>>>>>>> there is a simple way to exit a record loop by stopping the pcm, but
>>>>>>> without loosing pending frames.
>>>>>>>
>>>>>>> Initially, I was thinking of something like this, where I would call
>>>>>>> snd_pcm_drop(pcm) from some other thread:
>>>>>>>
>>>>>>>    while ( true )
>>>>>>>      {
>>>>>>>        r = snd_pcm_readi (pcm, data, frames);
>>>>>>>        fwrite (data, 2, 2*r, file);
>>>>>>>        if ( r != frames )
>>>>>>>          break;
>>>>>>>      }
>>>>>>>
>>>>>>> However, snd_pcm_drain(pcm) doesn't work here; the loop continues.
>>>>>>> snd_pcm_drop(pcm) breaks the loop, but pending frames are lost, and
>>>>>>> r=-EBADFD.
>>>>>>>
>>>>>>> Is there an easy way to stop snd_pcm_readi in a way that I can
>>>>>>> retrieve the residual frames? Do I need to set any parameters for
>>>>>>> that purpose?
>>>>>> If you're using hw or plughw, it's likely a bug in alsa-driver.
>>>>>> Try the patch below.
>>>>> Actually the patch was also wrong.  snd_pcm_drain() shouldn't wait for
>>>>> the capture streams.  So, the patch becomes pretty simple like below.
>>>>> I'll commit it to HG repo.
>>>>>
>>>>> Takashi
>>>>>
>>>>> diff -r 44d28ed5d3d5 core/pcm_native.c
>>>>> --- a/core/pcm_native.c	Wed May 17 11:26:39 2006 +0200
>>>>> +++ b/core/pcm_native.c	Wed May 17 17:07:17 2006 +0200
>>>>>  <at>  <at>  -1469,8 +1469,6  <at>  <at>  static int snd_pcm_drain(
>>>> struct snd_pcm_
>>>>>  		}
>>>>>  	}
>>>>>  	up_read(&snd_pcm_link_rwsem);
>>>>> -	if (! num_drecs)
>>>>> -		goto _error;
>>>>>
>>>>>  	snd_pcm_stream_lock_irq(substream);
>>>>>  	/* resume pause */
>>>> Hi Takashi,
>>>>
>>>> there seems to be some problem with this patch (the short one). After
>>>> recompiling the kernel (and my application), my application doesn't
>>>> exit and I can't kill it anymore. The pcm device is kind of lost. See
>>>> below for the /var/log/messages entry.
>>> Hmm, according the error message below, I suspect it's something
>>> different since the patch isn't so intrusive.
>>>
>>> Could you test again after reverting the patched part?
>> After recompiling the kernel with the original source, the problem
>> disappeared.
> 
> OK, could you try the patch below?
> 
> 
> thanks,
> 
> Takashi
> 
> 
> ------------------------------------------------------------------------
> 
> diff -r 18da48cda4cc core/pcm_native.c
> --- a/core/pcm_native.c	Mon May 22 12:05:42 2006 +0200
> +++ b/core/pcm_native.c	Mon May 22 12:39:22 2006 +0200
> @@ -1381,7 +1381,8 @@ static int snd_pcm_do_drain_init(struct 
>  		if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) {
>  			int state = snd_pcm_capture_avail(runtime) > 0 ?
>  				SNDRV_PCM_STATE_DRAINING : SNDRV_PCM_STATE_SETUP;
> -			snd_pcm_do_stop(substream, state);
> +			substream->ops->trigger(substream,
> +						SNDRV_PCM_TRIGGER_STOP);
>  			snd_pcm_post_stop(substream, state);
>  		}
>  	}

With this patch, I don't run into the same problem as with the last
one, i.e. there are no error messages.

However, it still doesn't do what I want - which is most probably my
own fault. In my program, there is one thread like this:

     while ( true )
       {
         r = snd_pcm_readi (pcm, data, frames);
         fwrite (data, 2, 2*r, file);
         if ( r != frames )
           break;
       }

My idea was to arrive at the break statement by calling
snd_pcm_drain(pcm) from another thread, but without loosing the
pending frames. If I understood Clemens Ladisch correctly, I will have
to use poll() for that purpose...

Thx,
Gerald