On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
At Sun, 5 Apr 2015 17:20:34 +0100, Russell King - ARM Linux wrote:
Since (afaik) ALSA has a lack of support for dynamic reconfiguration according to the attached device changing, the best we can do without a huge amount of re-work of HDMI support across all adapters is to process the capabilities of the attached device at prepare time according to the current capabilities.
Yeah, reconfiguration is tricky. BTW, how is the HDMI unplug handled during playback?
We don't handle it right now - and we don't have any notification to the audio drivers that that has happened. Even if we did have such a notification, I'm not sure what the audio driver could do with it at the moment.
Implementing dynamic reconfiguration in ALSA is not something I want to get involved with, and as we /already/ have HDMI support merged in the kernel, this is not a blocker for at least trying to get some semblence of sanity, rather than having every driver re-implementing stuff like this.
Well, I didn't mean about the dynamic reconfiguration. I thought of rather min/max pairs, but it was just a wrong assumption. Scratch it.
One another question: don't we need to deal with the sample bits in sad[2]?
It should, but I'm very wary about doing that without seeing more examples of real SADs. Right now, all my examples only support one SAD with either 2 channel or 6 channel audio at the standard (basic) 32, 44.1 and 48kHz rates.
The HDMI / CEA specs are very loose in their wording about the short audio descriptors. I've no idea whether a sink can provide (for example) descriptors such as:
LPCM, 6 channel 32, 44.1, 48kHz LPCM, 2 channel, 32, 44.1, 48, 96, 192kHz
or whether have to describe that as a single descriptor. I only have two TVs to test with here.
What I'm concerned about is that when the ALSA parameter refining starts, we start with (eg) 2-8 channels, 32-192kHz. Given that, if we invoke the channel restriction before the rate restriction, we would end up limiting to 2 channel at 32-192kHz. If we apply the restrictions in the opposite order, we'd restrict to 6 channel, 32-48kHz. Neither are obviously correct in this circumstance, and I don't really see a way to solve it given my understanding of the way ALSA's parameter refinement works.
I suspect this is why most HDMI drivers are implemented such that they take the maximum capabilities over all SADs, which would end up restricting audio in the above case to: up to 6 channels, at 32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't hasn't been indicated as supported.
Most of this is speculation though, based off what is in the documentation. As I say, I don't have enough real-world examples to get a feel for what manufacturers _actually_ do to give a hint as to how the documentation should be interpreted.
So, maybe I should just copy what everyone else does and take the maximum of all descriptors...