snd_pcm_wait returning EPIPE

snd_pcm_wait returning EPIPE

[Glenn Maynard]

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?

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: snd_pcm_wait returning EPIPE

[Takashi Iwai]

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.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: snd_pcm_wait returning EPIPE

[Glenn Maynard]

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 ...)

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: snd_pcm_wait returning EPIPE

[Takashi Iwai]

[-- 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 {

Re: snd_pcm_wait returning EPIPE

[Glenn Maynard]

On Mon, Oct 11, 2004 at 05:17:18PM +0200, Takashi Iwai wrote:
> 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?

Not directly, since I don't have access to the machine, but I'll pass it
on to the user and let you know.  Thanks.

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: snd_pcm_wait returning EPIPE

[Glenn Maynard]

On Mon, Oct 11, 2004 at 11:26:20AM -0400, Glenn Maynard wrote:
> On Mon, Oct 11, 2004 at 05:17:18PM +0200, Takashi Iwai wrote:
> > 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?
> 
> Not directly, since I don't have access to the machine, but I'll pass it
> on to the user and let you know.  Thanks.

Apparently no luck, but not much information and I'm not sure what to
try next:

https://sourceforge.net/tracker/?func=detail&atid=421366&aid=1035604&group_id=37892

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: snd_pcm_wait returning EPIPE

[Glenn Maynard]

On Mon, Oct 11, 2004 at 11:26:20AM -0400, Glenn Maynard wrote:
> On Mon, Oct 11, 2004 at 05:17:18PM +0200, Takashi Iwai wrote:
> > 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?
> 
> Not directly, since I don't have access to the machine, but I'll pass it
> on to the user and let you know.  Thanks.

Apparently no luck, but not much information and I'm not sure what to
try next:

https://sourceforge.net/tracker/?func=detail&atid=421366&aid=1035604&group_id=37892

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl