If I connect front panel sound jacks to my MB via HD Audio, not AC97 and plug headphones to the front output - Pulseaudio will be randomly and fast switch between front and rear inputs. Sound card - Relatek, Pulseaudio 4.0, Linux Mint 17.1 On Launchpad https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1067434
And another link https://bbs.archlinux.org/viewtopic.php?id=158991
(In reply to Yan Pashkovsky from comment #1) > And another link https://bbs.archlinux.org/viewtopic.php?id=158991 you have to post pulseaudio verbose log for Desktop with alc662 and three jacks at rear panel, only front playback volume and no headphone playback volume line out and headphone share front playback volume control
Where is this log? How to create it? Links' topics are created not by me, just similar problems
(In reply to Yan Pashkovsky from comment #0) > If I connect front panel sound jacks to my MB via HD Audio, not AC97 and > plug headphones to the front output - Pulseaudio will be randomly and fast > switch between front and rear inputs. > Sound card - Relatek, Pulseaudio 4.0, Linux Mint 17.1 > On Launchpad > https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1067434 post the output of alsa-info.sh to debug unsol jack plug and unplug event, you need to enable tracepoint and find out how those pin get sense command were triggered https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/HD-Audio.txt Tracepoints ~~~~~~~~~~~ The hd-audio driver gives a few basic tracepoints. `hda:hda_send_cmd` traces each CORB write while `hda:hda_get_response` traces the response from RIRB (only when read from the codec driver). `hda:hda_bus_reset` traces the bus-reset due to fatal error, etc, `hda:hda_unsol_event` traces the unsolicited events, and `hda:hda_power_down` and `hda:hda_power_up` trace the power down/up via power-saving behavior. Enabling all tracepoints can be done like ------------------------------------------------------------------------ # echo 1 > /sys/kernel/debug/tracing/events/hda/enable ------------------------------------------------------------------------ then after some commands, you can traces from /sys/kernel/debug/tracing/trace file. For example, when you want to trace what codec command is sent, enable the tracepoint like: ------------------------------------------------------------------------ # cat /sys/kernel/debug/tracing/trace # tracer: nop # # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | <...>-7807 [002] 105147.774889: hda_send_cmd: [0:0] val=e3a019 <...>-7807 [002] 105147.774893: hda_send_cmd: [0:0] val=e39019 <...>-7807 [002] 105147.999542: hda_send_cmd: [0:0] val=e3a01a <...>-7807 [002] 105147.999543: hda_send_cmd: [0:0] val=e3901a <...>-26764 [001] 349222.837143: hda_send_cmd: [0:0] val=e3a019 <...>-26764 [001] 349222.837148: hda_send_cmd: [0:0] val=e39019 <...>-26764 [001] 349223.058539: hda_send_cmd: [0:0] val=e3a01a <...>-26764 [001] 349223.058541: hda_send_cmd: [0:0] val=e3901a https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda?qt=grep&q=tracepoint
Created attachment 115861 [details] trace Attaching trace and alsa-conf. Is that all? Tracing was lasting for about 10 secs of plugged in front jack
Created attachment 115862 [details] alsa-conf
On Windows 7 the same happens about every 10 seconds (10 secs music strems to front, then 0.5 to rear, then again 5-15 secs to front), not 10 milliseconds like in Liniux
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/sound/hda_verbs.h this look like driver bug https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/HD-Audio.txt Hint Strings ~~~~~~~~~~~~ The codec parser have several switches and adjustment knobs for matching better with the actual codec or device behavior. Many of them can be adjusted dynamically via "hints" strings as mentioned in the section above. For example, by passing `jack_detect = no` string via sysfs or a patch file, you can disable the jack detection, thus the codec parser will skip the features like auto-mute or mic auto-switch. As a boolean value, either `yes`, `no`, `true`, `false`, `1` or `0` can be passed. The generic parser supports the following hints: - jack_detect (bool): specify whether the jack detection is available at all on this machine; default true - trigger_sense (bool): indicates that the jack detection needs the explicit call of AC_VERB_SET_PIN_SENSE verb - auto_mute (bool): enable/disable the headphone auto-mute feature; default true use early patching and hint try hint one by one to find out the cause disable power saving 1) do not execute AC_VERB_SET_PIN_SENSE (709) before AC_VERB_GET_PIN_SENSE (F09) trigger_sense=0 2) disable jack sense of headphone pin set bit 8 of pin default of headphone pin complex 3) disable jack detect of all pins jack_detect=0 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_realtek.c?id=1565cc358585be40608b46f18f7ac431a1aae2bc
<idle>-0 [003] d.h. 2438.427242: hda_unsol_event: [0] res=4000431, res_ex=10 <idle>-0 [003] dNh. 2438.427265: hda_unsol_event: [0] res=8000431, res_ex=10 kworker/u12:0-19272 [003] .... 2438.427284: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427285: hda_send_cmd: [0:0] val=1b70900 kworker/u12:0-19272 [003] .... 2438.427330: hda_get_response: [0:0] val=0 kworker/u12:0-19272 [003] .... 2438.427331: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427331: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427332: hda_send_cmd: [0:0] val=1bf0900 kworker/u12:0-19272 [003] .... 2438.427370: hda_get_response: [0:0] val=0 kworker/u12:0-19272 [003] .... 2438.427622: hda_send_cmd: [0:0] val=1970900 kworker/u12:0-19272 [003] .... 2438.427665: hda_get_response: [0:0] val=0 kworker/u12:0-19272 [003] .... 2438.427666: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427666: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427667: hda_send_cmd: [0:0] val=19f0900 kworker/u12:0-19272 [003] .... 2438.427703: hda_get_response: [0:0] val=80000000 idle>-0 [003] d.h. 2438.448554: hda_unsol_event: [0] res=4000491, res_ex=10 kworker/u12:0-19272 [003] d.h. 2438.448581: hda_unsol_event: [0] res=8000491, res_ex=10 kworker/u12:0-19272 [003] .... 2438.448589: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.448590: hda_send_cmd: [0:0] val=1b70900 kworker/u12:0-19272 [003] .... 2438.448644: hda_get_response: [0:0] val=0 kworker/u12:0-19272 [003] .... 2438.448645: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.448646: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.448646: hda_send_cmd: [0:0] val=1bf0900 kworker/u12:0-19272 [003] .... 2438.448685: hda_get_response: [0:0] val=80000000 <idle>-0 [003] d.h. 2438.725650: hda_unsol_event: [0] res=4000031, res_ex=10 <idle>-0 [003] dNh. 2438.725664: hda_unsol_event: [0] res=8000031, res_ex=10 kworker/u12:1-53 [003] .... 2438.725690: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:1-53 [003] .... 2438.725692: hda_send_cmd: [0:0] val=1b70900 kworker/u12:1-53 [003] .... 2438.725737: hda_get_response: [0:0] val=0 kworker/u12:1-53 [003] .... 2438.725737: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 kworker/u12:1-53 [003] .... 2438.725738: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 kworker/u12:1-53 [003] .... 2438.725739: hda_send_cmd: [0:0] val=1bf0900 kworker/u12:1-53 [003] .... 2438.725778: hda_get_response: [0:0] val=0 node 0x1b jack sense change frequently
I have no such file /lib/firmware/hda-init.fw How to use early patching? Download this file https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/sound/hda_verbs.h ... and how to compile it and where to place? And how to use hints? I have bunch of directories /sys/class/sound/hdaudioC0D0 /sys/class/sound/hdaudioC1D0 /sys/class/sound/hdaudioC1D1 /sys/class/sound/hdaudioC1D2 /sys/class/sound/hdaudioC1D3 and in each there is empty hints file. So I should echo to some /sys/class/sound/hdaudio????/hints lines like jack_detect=0 Will this changes be on the go or I need to reboot?
The hd-audio driver reads the file via request_firmware(). Thus, a patch file has to be located on the appropriate firmware path, typically, /lib/firmware. For example, when you pass the option `patch=hda-init.fw`, the file /lib/firmware/hda-init.fw must be present. The patch module option is specific to each card instance, and you need to give one file name for each instance, separated by commas. For example, if you have two cards, one for an on-board analog and one for an HDMI video board, you may pass patch option like below: ------------------------------------------------------------------------ options snd-hda-intel patch=on-board-patch,hdmi-patch
Early Patching ~~~~~~~~~~~~~~ When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a firmware file for modifying the HD-audio setup before initializing the codec. This can work basically like the reconfiguration via sysfs in the above, but it does it before the first codec configuration. A patch file is a plain text file which looks like below: ------------------------------------------------------------------------ [codec] 0x12345678 0xabcd1234 2 [model] auto [pincfg] 0x12 0x411111f0 [verb] 0x20 0x500 0x03 0x20 0x400 0xff [hint] jack_detect = no ------------------------------------------------------------------------ The file needs to have a line `[codec]`. The next line should contain three numbers indicating the codec vendor-id (0x12345678 in the example), the codec subsystem-id (0xabcd1234) and the address (2) of the codec. The rest patch entries are applied to this specified codec until another codec entry is given. Passing 0 or a negative number to the first or the second value will make the check of the corresponding field be skipped. It'll be useful for really broken devices that don't initialize SSID properly.
Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Front Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Front Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373e: IN OUT HP Detect Trigger Vref caps: HIZ 50 GRD 80 100 Pin Default 0x02a19850: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x5, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Front Headphone Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001373e: IN OUT HP EAPD Detect Trigger Vref caps: HIZ 50 GRD 80 100 EAPD 0x2: EAPD Pin Default 0x02214060: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x6, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=01, enabled=1 the two unsol_event tag (res>> AC_UNSOL_RES_TAG_SHIFT ) are assigned to front HP and front mic [003] d.h. 2438.448554: hda_unsol_event: [0] res=4000491, res_ex=10 [003] d.h. 2438.448581: hda_unsol_event: [0] res=8000491,
https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers (Sound/ALSA) this look like your front audio panel trigger unsol events for both jacks
Can't translate "unsol". Is it HW problem, our driver's?
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1269629 are your asrock p55pro ? but user did not mention which version of ubuntu is ok
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_realtek.c?id=29adc4b9e6a96571e83353cdcb69628871984935 the tag used was different before this patch may be event are related to DCVOL #define ALC_FRONT_EVENT 0x01 #define ALC_DCVOL_EVENT 0x02 #define ALC_HP_EVENT 0x04 #define ALC_MIC_EVENT 0x08
I use ASrock 870 extreme 3, crappy motherboard by the way.
kworker/u12:0-19272 [003] .... 2438.427331: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 kworker/u12:0-19272 [003] .... 2438.427331: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=cc72da7d4d063ab9e690e56e0ef1ca1c24ee1635 seem no longer use power_count try boot with livecd
usually only one unsolicited event for the pin when plug and unplug of the jack but you seem have unsol event for two pins https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1248116 thw workaround is disable the jack detect of problematic pin
With livecd all the same result. Well, I switched back to AC97 which is equal to HD Audio withoiut jack sensing.
seem only green jack different from other three line outs when response of get pin sense 0x80000000 driver mute four line out pins by set pin-ctl to zero Pin-ctls: 0x00: pulseaudio check the headphone jack control control.43 { iface CARD name 'Front Headphone Jack' value true comment { access read type BOOLEAN count 1 } } set the mute switch of the other three line out Amp-Out vals: [0x80 0x80] except green jack Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Line Out Front Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003e: IN OUT HP EAPD Detect Trigger EAPD 0x2: EAPD Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=05, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0c
I'm closing this, since this is not a PulseAudio bug.
And where to report it? Kernel? Alsa? Or ASrock?
As far as I can tell, the problem is faulty hardware, not a bug in any software. To make life less painful for users who have to live with such hardware, it would be nice to have a feature in PulseAudio or ALSA that would allow state detection for a particular jack to be easily disabled. Or even automatic disabling, if the jack activity seems bogus. If you want, you can file such feature request as a bug in this bugzilla for PulseAudio, or bring up the topic on the alsa-devel mailing list. (To manage expectations: I think it's unlikely that anyone will implement such features any time soon. I have added that to my own todo list, but that list has hundreds of other items too.)
Thank you. There is related issue of automuting https://bugs.freedesktop.org/show_bug.cgi?id=90496 when i connect front mic or headphones, sound from my speakers crackles too. Even if my front panel worked correctly - somebody doesn't want to mute other sound devices. Take a look at it please :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.