On 2014-07-13 14:12, Tanu Kaskinen wrote: > On Sun, 2014-07-13 at 13:29 +0200, David Henningsson wrote: >> >> On 2014-07-13 12:45, Tanu Kaskinen wrote: >>> On Sun, 2014-07-13 at 15:07 +0600, Alexander E. Patrakov wrote: >>>> Signed-off-by: Alexander E. Patrakov <patrakov at gmail.com> >>> >>> Looks good to me, but I wonder whether there was some reason for not >>> having a mapping for 7.1 when there already was a mapping for 5.1. >>> Before applying the patch, I'd like to give David a chance to comment >>> (he's on vacation for the next week). >>> >>> Somewhat related, I also wonder why the surround mappings (both 5.1 and >>> 7.1) are only in extra-hdmi.conf. My understanding is that the point of >>> extra-hdmi.conf is just to offer the additional mappings for the >>> subdevices 1-3, so the non-extra surround profiles should be copied to >>> all other profile-set files too. >>> >>> And still one related note: it seems that 5.1 mappings are missing for >>> the "extra" subdevices. >>> >>>> P.S. should I also upstream profiles that allow sending software-DTS-encoded >>>> stream to HDMI? >>> >>> Probably yes. >> >> Every new profile added is a trade-off: It takes some extra time (at >> startup or hotplug) to probe a profile. And we want computers to boot as >> fast as possible. >> >> Adding new profiles will increase the functionality but at the expense >> of longer startup time for everyone, regardless of whether they'll >> actually ever use that profile. >> >> That's the original reason why there is one extra-hdmi profile in the >> first place, to avoid extra time being spent probing hdmi stuff on e g >> USB headsets. >> >> That said, I think it makes sense to make some additional measurements. >> If we get stopped at the alsa-lib layer (e g because the "hdmi" name >> does not exist), then maybe there isn't much overhead to consider. >> >> So, it probably makes sense to >> * Merge extra-hdmi.conf into default.conf >> * Merge this patch as well >> * Allow up to 8 hdmi devices (alsa 1.0.28 has this addition) >> >> ...but the question is how much additional overhead this will mean for >> analog built-in audio, USB headsets, etc. Anybody who wants to do some >> research on this topic? > > I would hope that there's some way to start fast while also providing > all functionality out-of-the box. Is it so that we don't know for sure > whether the alsa probing phase actually adds any meaningful delay to the > start-up? Someone (not me, at least any time soon) could write a simple > patch that measures and logs (at error level - measurements shouldn't be > done at debug log level) the time that the probing takes. Then test it > on your development machine, and if the time seems negligible, try also > e.g. plugging in a USB sound card to a Raspberry Pi. Well, I have a USB sound card that takes about 400 ms to set the sample rate. I debugged this on USB protocol level once, so I know the delay is in the hardware. I hope that is the exception rather than the rule, and we don't change the sample rate when we probe profiles (IIRC) anyway, so that's just an example of delays we potentially could be dealing with. But a couple of 100 ms for all the probes are not that unusual for USB. I think, but again, measurements... > If the time isn't negligible, I'd be tempted to make the probing > asynchronous. We could start the probing from profiles that have the > highest priority (and if module-card-restore has set the profile, that > should be the highest-priority profile), then set the initial card > profile to the first profile that is found to be working, and continue > probing the rest of the profiles in the background. This sounds a bit complex, but I guess with profile availability it could be possible. Profiles are available=unknown if they haven't been probed yet, and then turn into =yes or =no after the probe. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
