From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre-Louis Bossart Subject: Re: Passing audio info from HDMI EDID beside speaker allocation Date: Tue, 23 Oct 2012 17:56:33 -0500 Message-ID: <508720A1.80208@linux.intel.com> References: <506E832C.50702@codeaurora.org> <508589A2.4080309@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by alsa0.perex.cz (Postfix) with ESMTP id BEFBD262626 for ; Wed, 24 Oct 2012 00:56:47 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: arun.raghavan@collabora.co.uk, Patrick Lai , alsa-devel List-Id: alsa-devel@alsa-project.org >>> In the case of HD-audio, it's passed via the normal IEC958 status bits >>> controls separately. ELD itself is exposed as a byte array in a >>> control element, but it's read-only. >> >> Thanks for the reply. Couple more questions >> >> 1. Is kcontrol "ELD" being read directly by application or there is >> ALSA library API to parse the information. > > Nothing so far. It's just a raw data. > >> 2. Also, I see you submit this patch [PATCH 3/3] ELD proc interface for >> HDMI sinks in 2008. I presume it's just for information purpose. You >> still expect application to query for HDMI sink capability through >> "ELD" kcontrol. Am I correct? > > It's not prohibited for apps to parse the proc interface but it's not > guaranteed to be stable :) So yes, parsing ELD manually would be a > safer way. I wrote some code to parse the ELD kcontrol to enable passthrough if AC3 is supported by the receiver, I believe it's been integrated by Arun in a branch of PulseAudio. It's probably 1 year old now..