[alsa-devel] [PATCH] - ALSA hda ad1988 - Add Independent HP Switch to model 6stack-dig-fp
tiwai at suse.de
Thu Apr 28 15:24:47 CEST 2011
At Thu, 28 Apr 2011 21:10:23 +0800,
Raymond Yau wrote:
> 2011/4/26 Takashi Iwai <tiwai at suse.de>
> > At Tue, 19 Apr 2011 08:12:57 +0800,
> > Raymond Yau wrote:
> > >
> > > Add Independent HP Switch to model 6stack-dig-fp
> > >
> > > allow user to switch Independent HP on/off by using ALSA specific "share
> > > stream" mode
> > >
> > > This don't need to make "Headphone Playback Volume" inactive but this
> > also
> > > mean that "Headphone Playback Volume" is no longer slave of the "Virtual
> > > Master" any more
> > The implementation looks almost OK (although there are a few pieces
> > of unused code slike activate_ctl()), I prefer an enum control for it.
> The other ad1988 models does not fully utilised five DACs
> This implementation is specific to 10 channels HDA ,as Front and Headphone
> just share the stream when "Independent HP" is off
> The "Independent HP" switch have to be write protected when any application
> is using multiout or alt_playback , alsamixer just display the inactive
> control in grey color.
> The driver return -EBUSY if any application try to open alt_playback when
> independent HP is switch off.
If it's really implemented :) You defined activate_ctl() but it's
called from nowhere.
> As for the upmixing feature, I wonder why no one complain about sending left
> channel to the center and right channel to subwoofer
Well, maybe because usually you set up 5.1 properly when you have such
systems, then upmixing right in the backend, not in the driver.
> > It's a frequently seen problem that user sets "Independent HP" mixer
> > switch accidentally and gets unexpected results. An enum control
> > tends to be more clear than a mixer switch in general.
> > This depend on how the mixer application treat the "inactive state" of
> control (e.g. qasmixer make the "inactive" control invisible )
No, this is a question how easily such feature can be changed
mistakenly. It's no technical question, but a design issue.
The mixer element itself isn't so self-explanatory, and people tend to
turn on every mixer switch once when something doesn't work and wonder
> Still unable to enable the unsolicited event for jack sense even if I add
> the unsol_event and verb for the audio jacks at rear panel since I don't
> have the HDA compilant front audio panel
> SoundMax automatically popup immediately when jack is plug into the rear
> panel at other OS, so the hardware is capable of jack sense at rear panel
> AFG Function Id: 0x1 (unsol 0)
> Is there any trick to enable/debug the unsolicited event ?
> seem unsol event is disabled in the HDA controller
No, there shouldn't be big differences. Otherwise it won't work on
any other machines.
There might be other way to trigger the jack detection, e.g. GPIO
unsolicited event, depending on the codec chip. I don't remember how
is AD1988, though...
More information about the Alsa-devel