Message-ID: <544A65DE.40108@osg.samsung.com>
Date:	Fri, 24 Oct 2014 08:44:46 -0600
From:	Shuah Khan <shuahkh@....samsung.com>
To:	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
	Takashi Iwai <tiwai@...e.de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Hans Verkuil <hverkuil@...all.nl>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>
CC:	alsa-devel@...a-project.org,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sander Eikelenboom <linux@...elenboom.it>,
	Prabhakar Lad <prabhakar.csengg@...il.com>,
	Antti Palosaari <crope@....fi>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	"sakari.ailus@...ux.intel.com" <sakari.ailus@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tim Gardner <tim.gardner@...onical.com>,
	"olebowle@....com" <olebowle@....com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media
 token api

On 10/22/2014 01:45 PM, Devin Heitmueller wrote:
>> 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.
> 

Sounds like we don't have a clear direction on open/close or capture
start/stop. What I am hearing is open/close isn't acceptable for
media maintainers and capture trigger start/stop isn't acceptable
to sound maintainers. :) Fork in the road, which way do we go?

Implementation wise, supporting capture trigger start/stop approach
will be harder to maintain in longterm. It adds more variables to
the mix. Applications open sounds device from the main thread and
then create a new thread to handle streams. I can see that based
on the token hold requests that come in. So the token hold logic
will have to take that into account, leading into potential
unbalanced lock/unlock scenarios. It is not impossible to solve,
that's what I did in this patch series, but it does get complex.

What I am looking for is some consensus on let's go with an approach
and try. Doesn't matter which way we go, and how much testing I do,
I am bound to miss something and this work needs to soak for a bit in
the media experimental branch.

thanks,
-- Shuah



-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@....samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists