From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: snd_pcm_wait returning EPIPE Date: Mon, 11 Oct 2004 17:17:18 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20041007152634.GK12858@zewt.org> <20041011141156.GU12858@zewt.org> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Mon_Oct_11_17:17:18_2004-1" Return-path: Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by alsa.alsa-project.org (ALSA's E-mail Delivery System) with ESMTP id 3BCA92D8 for ; Mon, 11 Oct 2004 17:24:07 +0200 (MEST) In-Reply-To: <20041011141156.GU12858@zewt.org> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Glenn Maynard Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org --Multipart_Mon_Oct_11_17:17:18_2004-1 Content-Type: text/plain; charset=US-ASCII 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 --Multipart_Mon_Oct_11_17:17:18_2004-1 Content-Type: text/plain; charset=US-ASCII 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 { --Multipart_Mon_Oct_11_17:17:18_2004-1-- ------------------------------------------------------- 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