From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: Possible message repeat Date: Mon, 25 Jun 2012 11:49:12 +0200 Message-ID: <4FE83418.7090401@ladisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by alsa0.perex.cz (Postfix) with ESMTP id D097924154 for ; Mon, 25 Jun 2012 11:49:14 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Brent Weatherall Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Brent Weatherall wrote: > our goal is to specify a special XU that WOULD require vendors > supporting it to modify their firmware. We fully expect a vendor to > modify their firmware to support our specification. That being said, > is there a simple way to use ALSA to communicate with a vendor > specific XU as long as the software understands the XU? For example, > in the video4linux2 world, we can specify a UVC XU with a set of > controls for special processing, then vendors that want to support it > modify their firmware to support it. Then anyone can use our custom > user-space drivers to easily talk to the video device. V4L2 has > controls made for using XUs in this manner. The audio class specification does not define any mechanism for a device to specify what those controls would be. And because nobody has ever needed to use XUs so far, the current ALSA driver has no other way to create such controls. If you insist on not changing ALSA, you must bypass it. Regards, Clemens