From: Takashi Iwai <tiwai@suse.de>
To: Glenn Maynard <glenn@zewt.org>
Cc: alsa-devel@alsa-project.org
Subject: Re: snd_pcm_wait returning EPIPE
Date: Mon, 11 Oct 2004 17:17:18 +0200 [thread overview]
Message-ID: <s5hfz4l4741.wl@alsa2.suse.de> (raw)
In-Reply-To: <20041011141156.GU12858@zewt.org>
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
At Mon, 11 Oct 2004 10:11:57 -0400,
Glenn Maynard wrote:
>
> On Mon, Oct 11, 2004 at 12:18:44PM +0200, Takashi Iwai wrote:
> > At Thu, 7 Oct 2004 11:26:34 -0400,
> > Glenn Maynard wrote:
> > >
> > > I've disabled the underrun state, eg. setting
> > > snd_pcm_sw_params_set_stop_threshold to dsnd_pcm_sw_params_get_boundary,
> > > which results in EPIPE never being returned from snd_pcm_wait (as I wanted),
> > > so I can handle underruns myself. I'm opening hw:0 directly, to avoid
> > > resampling.
> > >
> > > However, I'm receiving a report of a system returning EPIPE:
> > >
> > > https://sourceforge.net/tracker/index.php?func=detail&aid=1035604&group_id=37892&atid=421366
> > > https://sourceforge.net/tracker/download.php?group_id=37892&atid=421366&file_id=103978&aid=1035604
> > >
> > > This is apparently on an x86-64 system.
> > >
> > > Is this a known problem? Am I probably doing something wrong that just
> > > happens to usually work? I'm treating EPIPE as an unexpected condition,
> > > since it's not clear why it would happen here; should I have it call
> > > snd_pcm_prepare() and retry anyway?
> >
> > -EPIPE is usually buffer over/underrun (XRUN), so apps are supposed to
> > call snd_pcm_prepare() after receiving this.
>
> Right, I understand that. However, the docs say:
>
> "PCM is automatically stopped in SND_PCM_STATE_XRUN state when available
> frames is >= threshold. If the stop threshold is equal to boundary (also
> software parameter - sw_param) then automatic stop will be disabled
> (thus device will do the endless loop in the ring buffer)."
>
> However, after setting the stop threshold to boundary, I'm still getting
> this.
>
> The bug report says:
>
> "... tried to use 32 bits binaries after having installed all the necessary
> 32 bits libraries and having loaded the module snd-ioctl32 necessary when a 32
> applications tries to link with 64 bits alsa drivers."
>
> This is the only report of this I've received. Could there be a problem
> related to snd-ioctl32? I don't know exactly what the default boundary
> value represents, but it appears to be 0x40000000 on my system; if that
> scales to a similar 64-bit value (such as 0x4000000000000000) inside the
> 64-bit ALSA drivers, I could see problems. (But I'll stop guessing ...)
A good point. I guess you're right here. The 32bit ioctl wrapper
doesn't take care of the boundary value at all.
Could you try the attached patch?
Takashi
[-- Attachment #2: Type: text/plain, Size: 2182 bytes --]
Index: alsa-kernel/core/ioctl32/pcm32.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/ioctl32/pcm32.c,v
retrieving revision 1.23
diff -u -r1.23 pcm32.c
--- alsa-kernel/core/ioctl32/pcm32.c 15 Sep 2004 09:04:26 -0000 1.23
+++ alsa-kernel/core/ioctl32/pcm32.c 11 Oct 2004 15:09:43 -0000
@@ -169,11 +169,61 @@
DEFINE_ALSA_IOCTL(pcm_uframes_str);
DEFINE_ALSA_IOCTL(pcm_sframes_str);
-DEFINE_ALSA_IOCTL_BIG(pcm_hw_params);
DEFINE_ALSA_IOCTL(pcm_sw_params);
DEFINE_ALSA_IOCTL(pcm_channel_info);
DEFINE_ALSA_IOCTL(pcm_status);
+static int _snd_ioctl32_pcm_hw_params(unsigned int fd, unsigned int cmd, unsigned long arg, struct file *file, unsigned int native_ctl)
+{
+ snd_pcm_file_t *pcm_file;
+ snd_pcm_substream_t *substream;
+ snd_pcm_runtime_t *runtime;
+ struct sndrv_pcm_hw_params32 *data32;
+ struct sndrv_pcm_hw_params *data;
+ mm_segment_t oldseg;
+ int err;
+
+ /* FIXME: need to check whether fop->ioctl is sane */
+ pcm_file = file->private_data;
+ substream = pcm_file->substream;
+ snd_assert(substream && substream->runtime, return -ENXIO);
+
+ data32 = kmalloc(sizeof(*data32), GFP_KERNEL);
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (data32 == NULL || data == NULL) {
+ err = -ENOMEM;
+ goto __end;
+ }
+ if (copy_from_user(data32, (void __user *)arg, sizeof(*data32))) {
+ err = -EFAULT;
+ goto __end;
+ }
+ memset(data, 0, sizeof(*data));
+ convert_from_32(pcm_hw_params, data, data32);
+ oldseg = get_fs();
+ set_fs(KERNEL_DS);
+ err = file->f_op->ioctl(file->f_dentry->d_inode, file, native_ctl, (unsigned long)data);
+ set_fs(oldseg);
+ if (err < 0)
+ goto __end;
+ err = 0;
+ convert_to_32(pcm_hw_params, data32, data);
+ if (copy_to_user((void __user *)arg, data32, sizeof(*data32)))
+ err = -EFAULT;
+ /* recalcuate the boundary within 32bit */
+ runtime = substream->runtime;
+ runtime->boundary = runtime->buffer_size;
+ while (runtime->boundary * 2 <= 0x7fffffffUL - runtime->buffer_size)
+ runtime->boundary *= 2;
+ __end:
+ if (data)
+ kfree(data);
+ if (data32)
+ kfree(data32);
+ return err;
+}
+
+
/*
*/
struct sndrv_xferi32 {
next prev parent reply other threads:[~2004-10-11 15:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 15:26 snd_pcm_wait returning EPIPE Glenn Maynard
2004-10-11 10:18 ` Takashi Iwai
2004-10-11 14:11 ` Glenn Maynard
2004-10-11 15:17 ` Takashi Iwai [this message]
2004-10-11 15:26 ` Glenn Maynard
2004-10-12 19:30 ` Glenn Maynard
2004-10-12 19:31 ` Glenn Maynard
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=s5hfz4l4741.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=glenn@zewt.org \
/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.