From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751270AbeEMKkd (ORCPT ); Sun, 13 May 2018 06:40:33 -0400 Received: from mx2.suse.de ([195.135.220.15]:48602 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbeEMKkb (ORCPT ); Sun, 13 May 2018 06:40:31 -0400 Date: Sun, 13 May 2018 12:40:29 +0200 Message-ID: From: Takashi Iwai To: "Zengtao (B)" Cc: "perex@perex.cz" , "tiwai@suse.com" , "alsa-devel@alsa-project.org" , "linux-kernel@vger.kernel.org" Subject: Re: [alsa-devel] Timeout issues in wait_for_avail function In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED0C8D7B4E@DGGEMM506-MBS.china.huawei.com> References: <678F3D1BB717D949B966B68EAEB446ED0C8D7B4E@DGGEMM506-MBS.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 07 May 2018 12:49:34 +0200, Zengtao (B) wrote: > > Hi perex and tiwai: > > I have met a timeout case when capture audio from snd-usb-audio device, > when the host call the pcm_read and get into the wait_for_avail function. > The following happends > 1. No available data for capture(maybe because of the late response audio data by the uac device) Hrm, in the case of capture, the data must be available. If it's not the case, something is wrong. > 2. The current thread falls into sleep state and no one wakes up it. > 3. The current thread will sleep 10s(schedule_timeout(1000)) and then wakeup. > > I have two question about the wait_for_avail: > 1. The timeout value too long, is it a reasonable value? > 2. Is there any mechanism to wake up the thread if there is data from the hw. The scenario above shouldn't happen, so no need for discussion. Rather we should check why it's woken up even though no data is available. You can check the tracepoints to see the action of PCM stream, and confirm whether it's really no data, or it's just lost by some reason (or looks as if so). Takashi