Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932571AbaJVTpx (ORCPT ); Wed, 22 Oct 2014 15:45:53 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:61718 "EHLO mail-qa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932219AbaJVTpv (ORCPT ); Wed, 22 Oct 2014 15:45:51 -0400 MIME-Version: 1.0 In-Reply-To: <544804F1.7090606@linux.intel.com> References: <543FB374.8020604@metafoo.de> <543FC3CD.8050805@osg.samsung.com> <543FD1EC.5010206@osg.samsung.com> <543FD892.6010209@osg.samsung.com> <54467EFB.7050800@xs4all.nl> <544804F1.7090606@linux.intel.com> Date: Wed, 22 Oct 2014 15:45:42 -0400 Message-ID: Subject: Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api From: Devin Heitmueller To: Pierre-Louis Bossart Cc: Takashi Iwai , alsa-devel@alsa-project.org, Lars-Peter Clausen , Linux Media Mailing List , Greg Kroah-Hartman , "ramakrmu@cisco.com" , Shuah Khan , Hans Verkuil , Sander Eikelenboom , Prabhakar Lad , Antti Palosaari , Laurent Pinchart , "sakari.ailus@linux.intel.com" , Andrew Morton , Tim Gardner , "olebowle@gmx.com" , Linux Kernel , Mauro Carvalho Chehab Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for some > time after clients stop recording. Closing VLC in your example doesn't > immediately close the ALSA device. look for module-suspend-on-idle in your > default.pa config file. The ALSA userland emulation in PulseAudio is supposed to faithfully emulate the behavior of the ALSA kernel ABI... except when it doesn't, then it's not a bug but rather a feature. :-) > I also agree that the open/close of the alsa device is the only way to > control exclusion. I was also a proponent that we should have fairly coarse locking done at open/close for the various device nodes (ALSA/V4L/DVB). The challenge here is that we have a large installed based of existing applications that rely on kernel behavior that isn't formally specified in any specification. Hence we're forced to try to come up with a solution that minimizes the risk of ABI breakage. If we were doing this from scratch then we could lay down some hard/fast rules about things apps aren't supposed to do and how apps are supposed to respond to those exception cases. Unfortunately we don't have that luxury here. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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/