Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751533AbaJPOsK (ORCPT ); Thu, 16 Oct 2014 10:48:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49629 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbaJPOsI (ORCPT ); Thu, 16 Oct 2014 10:48:08 -0400 Date: Thu, 16 Oct 2014 16:48:03 +0200 Message-ID: From: Takashi Iwai To: Shuah Khan Cc: Lars-Peter Clausen , m.chehab@samsung.com, akpm@linux-foundation.org, gregkh@linuxfoundation.org, crope@iki.fi, olebowle@gmx.com, dheitmueller@kernellabs.com, hverkuil@xs4all.nl, ramakrmu@cisco.com, sakari.ailus@linux.intel.com, laurent.pinchart@ideasonboard.com, perex@perex.cz, prabhakar.csengg@gmail.com, tim.gardner@canonical.com, linux@eikelenboom.it, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, linux-media@vger.kernel.org Subject: Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api In-Reply-To: <543FD892.6010209@osg.samsung.com> References: <543FB374.8020604@metafoo.de> <543FC3CD.8050805@osg.samsung.com> <543FD1EC.5010206@osg.samsung.com> <543FD892.6010209@osg.samsung.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/24.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 At Thu, 16 Oct 2014 08:39:14 -0600, Shuah Khan wrote: > > On 10/16/2014 08:16 AM, Takashi Iwai wrote: > > At Thu, 16 Oct 2014 08:10:52 -0600, > > Shuah Khan wrote: > >> > >> On 10/16/2014 08:01 AM, Takashi Iwai wrote: > >>> At Thu, 16 Oct 2014 07:10:37 -0600, > >>> Shuah Khan wrote: > >>>> > >>>> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote: > >>>>> On 10/14/2014 04:58 PM, Shuah Khan wrote: > >>>>> [...] > >>>>>> switch (cmd) { > >>>>>> case SNDRV_PCM_TRIGGER_START: > >>>>>> + err = media_get_audio_tkn(&subs->dev->dev); > >>>>>> + if (err == -EBUSY) { > >>>>>> + dev_info(&subs->dev->dev, "%s device is busy\n", > >>>>>> + __func__); > >>>>> > >>>>> In my opinion this should not dev_info() as this is out of band error > >>>>> signaling and also as the potential to spam the log. The userspace > >>>>> application is already properly notified by the return code. > >>>>> > >>>> > >>>> Yes it has the potential to flood the dmesg especially with alsa, > >>>> I will remove the dev_info(). > >>> > >>> Yes. And, I think doing this in the trigger isn't the best. > >>> Why not in open & close? > >> > >> My first cut of this change was in open and close. I saw pulseaudio > >> application go into this loop trying to open the device. To avoid > >> such problems, I went with trigger stat and stop. That made all the > >> pulseaudio continues attempts to open problems go away. > > > > But now starting the stream gives the error, and PA would loop it > > again, no? > > > > > >>> Also, is this token restriction needed only for PCM? No mixer or > >>> other controls? > >> > >> snd_pcm_ops are the only ones media drivers implement and use. So > >> I don't think mixer is needed. If it is needed, it is not to hard > >> to add for that case. > > > > Well, then I wonder what resource does actually conflict with > > usb-audio and media drivers at all...? > > > > audio for dvb/v4l apps gets disrupted when audio app starts. For > example, dvb or v4l app tuned to a channel, and when an audio app > starts. audio path needs protected to avoid conflicts between > digital and analog applications as well. OK, then concentrating on only PCM is fine. But, I'm still not convinced about doing the token management in the trigger. The reason -EBUSY doesn't work is that it's the very same error code when a PCM device is blocked by other processes. And -EAGAIN is interpreted by PCM core to -EBUSY for historical reasons. How applications (e.g. PA) should behave if the token get fails? Shouldn't it retry or totally give up? Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/