Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/23/2012 07:44 PM, Ricardo Neri wrote:
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
>> At Tue, 21 Aug 2012 19:58:02 -0500,
>> Ricardo Neri wrote:
...
>>> Maybe the lack of audio support in drm is because the audio users should
>>> not talk to drm directly but to a lower level component (omapdrm,
>>> omapdss?). However, today there exists video technology supports audio
>>> as well, such as DisplayPort or HDMI. Could it make more sense now to
>>> provide audio support?
>>
>> The reason is that the audio and video handling are already separated
>> in the hardware level, at least, for desktop graphics.
> 
> Separated in what sense? Do they have separate register banks in

For NVIDIA desktop GPUs, this is certainly true, and I think so for any
Intel Azalia/HDA controller. The separate register banks are in
different PCI functions on the chip. The Intel Azalia/HDA spec also
architects specific ways that the audio and video parts interact (i.e.
ELD representation of EDID data, unsolicited response messages when the
video state changes, etc.) Oh, I see Takashi mentioned this below.

> independent power domains?

Most likely yes.

> Can audio an video work with complete
> independence. What happens if someone decides to power off video. Is the
> audio able to continue if required?

I believe audio DMA isn't affect by the video state, but I'm not 100%
sure of that.

>> The audio infoframe is passed via ELD to the audio controller part
>> upon plug/unplugging via HD-audio unsolicited event, and the audio
>> driver sets up the stuff according to the given ELD.  Thus no extra
>> interface between drm and ALSA was required in the kernel API level,
>> so far.
> 
> I see that the unsolicited event is used only to parse the EDID,
> correct? It also notifies about the jack status. Hence, if there the
> cable is disconnected the application will know and act accordingly. Is
> this understanding correct?

The kernel will know, and then passes the information on to user-space.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux