[alsa-devel] Intel HDA audio on EEE PC 1101HGo

[Enrico Mioso]

Unfortunately I don't have the required competence to understand at the moment 
where those flags are in the relevant structs. And, unfortunately also, the 
"time"/environment. I'll let you know in case, I would like to help here.


Enrico Mioso
My Tox ID is:
1CE0149BA3E39A140B5AE1B2FEA1C0A1F92418345B829DA03F62583412E7474293C6F48A97E9

I like / reocmmend usage of open messaging standards: here are my XMPP IDs.
JIDs list:
- mrkiko at jit.si
- mrkiko at jabber.linux.it
- mrkiko at chrome.pl
- mrkiko at chatme.xyz
- mrkiko at alpha-labs.net

(XMPP allows server to server communications, so you might write to me using
any of these JIDs regardless the server you're connected to if
administratively allowed by your server or the destination one; I wanted to
see if some servers offered "innovative" / different services / for "fun",
still I am not experienced enough to discover them confortably. One JID would
have been enough.)

On Sun, 12 Apr 2015, Takashi Iwai wrote:

==Date: Sun, 12 Apr 2015 08:01:17
==From: Takashi Iwai <tiwai at suse.de>
==To: Enrico Mioso <mrkiko.rs at gmail.com>
==Cc: perex at perex.cz, hui.wang at canonical.com, david.henningsson at canonical.com,
==    kailang at realtek.com, alsa-devel at alsa-project.org
==Subject: Re: Intel HDA audio on EEE PC 1101HGo
==
==At Sat, 11 Apr 2015 10:13:51 +0200 (CEST),
==Enrico Mioso wrote:
==> 
==> When I plug in the jack and the audio is going, sometimes the audio will go to 
==> the headphones and to the PC speakers.
==
==It means that the unsol event hasn't been processed correctly.  We
==need to debug via trace points which verb triggers this, for example.
==(See Documentation/sound/alsa/HD-Audio.txt.)
==
==Usually when a communication stall happens it reports switching to
==polling mode.  This is already a suspect.  The stall at powering down
==to D3 is known on some codecs / controllers, so this itself isn't too
==serious.  But if this happens at anything else, it needs more care.
==
==> But stopping the audio and waiting for 
==> the controller to enter power save mode, and starting it again, solves the 
==> problem. But in my situation I had to ask the driver to reset the controller 
==> any time it exits power save:
==> options snd_hda_intel power_save_controller=1 power_save=5
==> so - I think the driver is not able to communicate properly with the device due 
==> to problems elsewhere, not of it's own. I would like so much to see what 
==> windows does in these cases. :)
==
==Yes, it's very likely some communication error that makes the codec
==hang.  It's interesting that the controller power save fixes it.  This
==implies that the problem is rather in the controller side.
==What if you set the following flags?
==	codec->bus->sync_write = 1;
==	codec->bus->allow_bus_reset = 1;
==
==
==Takashi
==
==> thank you guys for your work again - this intended to be an hilarious mail.
==> Have a good weekend.
==> Enrico
==> 
==> I have CONFIG_SND_HDA_INPUT_JACK=y (I know it's uncorrelated).
==> On Thu, 9 Apr 2015, Takashi Iwai wrote:
==> 
==> ==Date: Thu, 9 Apr 2015 17:59:15
==> ==From: Takashi Iwai <tiwai at suse.de>
==> ==To: Enrico Mioso <mrkiko.rs at gmail.com>
==> ==Cc: perex at perex.cz, hui.wang at canonical.com, david.henningsson at canonical.com,
==> ==    kailang at realtek.com, alsa-devel at alsa-project.org
==> ==Subject: Re: Intel HDA audio on EEE PC 1101HGo
==> ==
==> ==At Wed, 8 Apr 2015 21:40:53 +0200 (CEST),
==> ==Enrico Mioso wrote:
==> ==> 
==> ==> Hello guys.
==> ==> I am writing to you all to talk you about a strange behaviour of the Intel HDA 
==> ==> Audio device on an EEE PC 1101H.
==> ==> The audio device at some point simply doesn't react to commands, giving in 
==> ==> dmesgo utput like this:
==> ==> 
==> ==> [22321.638079] snd_hda_intel 0000:00:1b.0: azx_get_response timeout, switching 
==> ==> to polling mode: last cmd=0x00170503
==> ==> [22322.641410] snd_hda_intel 0000:00:1b.0: azx_get_response timeout, switching 
==> ==> to single_cmd mode: last cmd=0x00170503
==> ==
==> ==This looks already bad.  It means that power down of the codec
==> ==failed.
==> ==
==> ==But, the recent version should ignore this error.  There was a logic
==> ==failure to check this, but this was corrected recently.
==> ==
==> ==Could you check the latest 4.0-rc whether it works better?
==> ==If not, take alsa-info.sh output snapshots at good and bad working
==> ==moments.  Run the script with --no-upload option, and attach the
==> ==outputs (better compressed).
==> ==
==> ==
==> ==Takashi
==> ==
==> 
==