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. 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. -- Tanu
