At Mon, 9 Sep 2013 18:01:41 +1000, Ian Munsie wrote:
Hi Raymond,
On 26 August 2013 11:55, Raymond Yau superquad.vortex2@gmail.com wrote:
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documenta...
have you try those gpio ?
Thanks for the pointer - I finally got around to trying this (it's not my primary box) and was able to get the speaker to work by enabling GPIO 0 as an output with data=1 (i.e. I selected out-dir, enable and data in hda-analyzer).
I noticed that the GPIO settings would clear when I stopped playing sound though, so I currently have to run the python script generated by hda-analyzer every time I want to play a sound through the speaker. I also noticed that I had to manually set data=0 to turn the speaker off if I plugged in the headphones.
What is the next step in fixing this properly? I've been meaning to look through the hda code to figure out how these kind of quirks are supposed to be handled, but haven't got around to that yet.
Please give alsa-info.sh output, then we'll provide some trivial test patches. At best, run alsa-info.sh with --no-upload option and attach the output.
or specify hints primary_hp = false
That did nothing by itself, though come to think of it I didn't try it in combination with the GPIO settings.
it is strange that driver select amp at pin complex of headphone as headphone volume control instead of amp at audio output ( the number of step and dB range of headphone and speaker is different )
you may need to change the logic of look_for_out_vol_nid() in hda_generic.c
Hmm, the volume control seemed to be working for me with both speakers & headphones, but I didn't check which control it was actually changing.
you may need cs4208 datasheet if the codec need vendor coefff
why virtual master did not warn when the dB range and number of step in slaves controls are different ?
Is that something I need to be concerned about? Where should that warning have appeared?
If GPIO does fix the issue, that's all what we need.
Takashi