On Wed, 2012-01-11 at 17:03 +0100, David Henningsson wrote: > With 3.3 merge window opened, and the new jack detection interface > scheduled to go in, maybe it's time to talk about the implementation as > well. > > My draft patch is here: > http://kernel.ubuntu.com/git?p=diwic/pulseaudio.git;a=commit;h=1f239a9966fe7e43d3c9cb37fedabf31ff7d706e > > Fetching the jack state is done through the alsa-lib hctl interface, > whereas the existing mixer stuff uses the alsa-lib smixer interface, > which layers on top of the hctl interface. Right now I've tried to reuse > the existing mixer code, which leads to stuff such as: > > if (fdl->hctl) > err = snd_hctl_poll_descriptors_revents(fdl->hctl, > fdl->work_fds, fdl->num_fds, &revents); > else > err = snd_mixer_poll_descriptors_revents(fdl->mixer, > fdl->work_fds, fdl->num_fds, &revents); > > Looks a bit copy-pasted, but I think it is the easiest solution at the > moment. It's just five or so places anyway. > The other option would be to try to port the entire mixer stuff to use > the hctl interface instead of the smixer interface, but I'm not sure I > can foresee how much trouble that actually would be, and if we would run > in to any regressions. > > Thoughts? The current approach of using hctl and smixer side by side looks ok to me. A couple of questions: Supposedly the simple mixer interface is significantly simpler in some way. If we moved to hctl entirely, do you know roughly how much there would be extra complexity? A lot, a little or are the two interfaces about the same? Do you know in what ways the simple interface is simpler? If there's no explosion of unnecessary code resulting from moving to hctl, I'd file a wishlist bug. Otherwise we can just forget about it. Have the alsa developers said anything about adding the jack stuff to the smixer interface? -- Tanu
