Em Ter, 2009-06-02 às 14:10 -0300, Gustavo Maciel Dias Vieira escreveu:
Em Qua, 2009-04-29 às 08:37 +0200, Takashi Iwai escreveu:
OK, it means that the unsolicited event isn't processed properly at jack plugging. But still strange why alsa-info.sh can trigger it.
Could you put some debug print to the unsol even handler to see whether you get any even when you plug the jack?
The stac92xx_unsol_event() isn't called when the jack is plugged. It is called twice at kernel boot (HP_EVENT and then INSERT_EVENT), and it is called three times when running alsa-info (all HP_EVENT, regardless if the HP is plugged or not).
These results may not be entirely accurate as the current snapshot isn't working correctly. It just plays the first second of audio and keeps looping, locking the application (with and without pulseaudio).
If it would help you, I could try to debug stac92xx_unsol_event() in the current Fedora kernel (2.6.29.4), as the sound works with it and the jack sensing don't.
I repeated the experiment with the Fedora kernel 2.6.29.4. The results are exactly the same. stac92xx_unsol_event() isn't called when the jack is plugged or unplugged, and alsa-info triggers a number of HP_EVENTs.
However, this time I made an interesting observation. alsa-info does not generate spurious events. It generates exactly the number of events that should be generated before the execution of alsa-info. For example: if I plug and unplug the HP and run alsa-info, two HP_EVENTs are generated. This explains the three events I observed earlier (plug, unplug, plug, alsa-info).
It seems the events are getting "stuck" somewhere and alsa-info "releases" them.
Abraços, Gustavo