All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Gerald Grabner <gerald.grabner@gmx.net>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Re: quit snd_pcm_readi, retrieve pending frames
Date: Sat, 20 May 2006 15:07:41 +0200	[thread overview]
Message-ID: <s5hiro0n8te.wl%tiwai@suse.de> (raw)
In-Reply-To: <loom.20060519T230916-804@post.gmane.org>

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

  reply	other threads:[~2006-05-20 13:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-13 11:06 quit snd_pcm_readi, retrieve pending frames Gerald Grabner
2006-05-14 13:07 ` Clemens Ladisch
2006-05-15 10:06 ` Takashi Iwai
2006-05-17 15:08   ` Takashi Iwai
2006-05-19 21:17     ` Gerald Grabner
2006-05-20 13:07       ` Takashi Iwai [this message]
2006-05-20 18:46         ` Gerald Grabner
2006-05-22 10:41           ` Takashi Iwai
2006-05-22 16:28             ` Takashi Iwai
2006-06-04 11:51             ` Gerald Grabner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hiro0n8te.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=gerald.grabner@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.