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... -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
