Created attachment 245791 [details] alsa-info On a Skylake based Samsung Tabpro S tablet I am having two alsa issues on 4.7.0, 4.8.0-rc5 and 4.9-rc2: - no output on speaker with any possible configuration, but audio over headphone jack works - playback speed/pitch is doubled (audible over headphones) Sound works fine in Windows obviously, but rebooting from Windows to Linux (as opposed to cold boot) doesn't seem to have any influence on these issues. I've tried modprobing with all the various ALC model quirks to no avail. I've tried toggling various options with amixer (Auto Mute, various speaker related values with amixer cset) and even played with hda-analyzer.py and hda-jack-retask but was unable to get anything from the speakers whatsoever, nor was I able to reduce the double speed/pitch playback.
(In reply to infernix from comment #0) > Created attachment 245791 [details] > - no output on speaker with any possible configuration, but audio over > headphone jack works This is a oft-seen problem, but... > - playback speed/pitch is doubled (audible over headphones) ... this one is weird. For further debugging, try to disable PulseAudio and test only with aplay / arecord at first. This reduces the possible causes. That is, test like % aplay -Dplughw foo.wav If this still causes the high pitch, try to figure out how fast it is skewed. About the speaker issue, it's possibly some GPIO pin or something like that controlling the speaker amp in addition. Windows driver may have some extra information mentioning such a thing.
I did not mention it but all pulseaudio packages are purged during testing; this is purely on alsa. As far as the skew, a 44.1khz wav file that plays with aplay -Dplughw for 1.514s-1.520s on any other device plays for 0.760-0.780s on this one, so presumably playback is running at 88.2khz. So looks like 200% playback speed on youtube etc. I looked at the windows registry and did find mention of some pins but playing around with them in hda-jack-retask or the analyzer didn't get me anywhere; are there specific tools to get this data from windows?
I've tried a bunch of GPIOs with the following code: for NID in 0x01 0x1a; do for MASK1 in 0 ; do for MASK2 in 1 2 3 4 5; do for DIR1 in 0; do for DATA1 in 0; do for DIR2 in 0 1 2 3 4 5; do for DATA2 in 0 1 2 3 4 5; do hda-verb /dev/snd/hwC0D0 ${NID} SET_GPIO_MASK 0x${MASK1}${MASK2}; hda-verb /dev/snd/hwC0D0 ${NID} SET_GPIO_DIR 0x${DIR1}${DIR2}; hda-verb /dev/snd/hwC0D0 ${NID} SET_GPIO_DATA 0x${DATA1}${DATA2} echo nid ${NID} mask 0x${MASK1}${MASK2} dir 0x${DIR1}${DIR2} data 0x${DATA1}${DATA2} amixer sset Speaker mute 0%; amixer sset Master unmute 100%; amixer sset Speaker unmute 100%; time aplay -Dplughw voice.wav; done; done; done; done; done; done; done That did not lead to any result unfortunately. Did I miss any combinations with the above code? I looked at the windows drivers but there was no ini and the inf files didn't help either. The only thing I gathered from grepping strings in the Realtek drivers was that there's mention of Set_EAPD_Status but nothing concerning GPIO. When looking in the registry, I see pin 12 and pin 18 mapped to Mic-In and pin 17 to Headphones but no mention of any pinXX for speaker (based on https://www.reaper-x.com/2012/02/13/how-to-remap-retasking-realtek-onboard-jacks-ports/). I do see a lot of CaliDataXYY entries. I've attached a codecgraph as well. The windows driver has an option to either a) mute speaker when headphone is inserted or b) play separate streams over headphone jack and built-in speakers; is b) perhaps what is the default and that's why there's no audio?
Created attachment 245821 [details] codecgraph
(In reply to infernix from comment #2) > I did not mention it but all pulseaudio packages are purged during testing; > this is purely on alsa. > > As far as the skew, a 44.1khz wav file that plays with aplay -Dplughw for > 1.514s-1.520s on any other device plays for 0.760-0.780s on this one, so > presumably playback is running at 88.2khz. So looks like 200% playback speed > on youtube etc. Just an idea: could you try with 32bit samples, not 16bit? You can convert the WAV file beforehand via sox, and play with aplay. At best, use 48kHz.
32bits alone did not help, but in the processs I did determine that the rate is not 88.2khz; it's 96khz. Converting a 44.1 mono voice sample to 96khz stereo in both 16 and 32bit and playback with -Dhw results in 100% accurate playback, accompanied with "rate is not accurate (requested 96khz, got 48khz). -Dplughw resamples it and playback is too fast again. Is there some way to force the driver to accept that the hardware clock is 96khz and resample accordingly? Or to somehow reinit the codec at 44.1/48khz?
I've tested setting the codec to 96khz with a patch similar to alc269_fixup_pcm_44k() (e.g. spec->stream_analog/digital_playback), but that did not have the right result; in fact the audio is then sped up even more (so 400% playback speed). Perhaps I'm Further attempts at turning on speaker output with hda-analyzer have failed; I also looked at whether if the codec is driven through I2S but I can't find any evidence for this at all. I even contacted Samsung but unsurprisingly they provide zero support when running Linux.
(In reply to infernix from comment #7) > I've tested setting the codec to 96khz with a patch similar to > alc269_fixup_pcm_44k() (e.g. spec->stream_analog/digital_playback), but that > did not have the right result; in fact the audio is then sped up even more > (so 400% playback speed). Perhaps I'm > > Further attempts at turning on speaker output with hda-analyzer have failed; > I also looked at whether if the codec is driven through I2S but I can't find > any evidence for this at all. I even contacted Samsung but unsurprisingly > they provide zero support when running Linux. The codec chip dosn't support 96kHz so the change about the rate wouldn't make sense. It's more about the link setup issue, I suppose. Just for a test: could you check whether the following change adjusting the rate? --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -774,6 +774,9 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, if (!rate_bits[i].hz) return 0; + val = (val & ~AC_FMT_MULT_SHIFT_MASK) | + ((val & AC_FMT_MULT_SHIFT_MASK) * 2 + (1 << AC_FMT_MULT_SHIFT)); + if (channels == 0 || channels > 8) return 0; val |= channels - 1; Also, what's about recording? Does it ever work in the sane behavior?
Recording works fine at 48khz, meaning if I record the mic with something like Audacity and play it back on another box, it sounds correct. As for the patch: sound/hda/hdac_device.c:777:16: error: ‘AC_FMT_MULT_SHIFT_MASK’ undeclared (first use in this function) Where is this defined? I can only find: ./include/sound/hda_verbs.h:#define AC_FMT_MULT_SHIFT 11 ./include/sound/hda_verbs.h:#define AC_FMT_MULT_MASK (7 << 11)
(In reply to infernix from comment #9) > Recording works fine at 48khz, meaning if I record the mic with something > like Audacity and play it back on another box, it sounds correct. It's interesting. > As for the patch: > > sound/hda/hdac_device.c:777:16: error: ‘AC_FMT_MULT_SHIFT_MASK’ undeclared > (first use in this function) > > Where is this defined? I can only find: > > ./include/sound/hda_verbs.h:#define AC_FMT_MULT_SHIFT 11 > ./include/sound/hda_verbs.h:#define AC_FMT_MULT_MASK (7 << 11) Yes, I forgot to add the inclusion of <sound/hda_verbs.h> But this will break recording, just a test. (And maybe this is wrong, it may give faster :)
I tried it like this: --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -774,6 +774,9 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, if (!rate_bits[i].hz) return 0; + val = (val & ~AC_FMT_MULT_MASK) | + ((val & AC_FMT_MULT_MASK) * 2 + (1 << AC_FMT_MULT_SHIFT)); + if (channels == 0 || channels > 8) return 0; val |= channels - 1; The above patch again doubles playback speed to 400% compared to unpatched at 200%.
OK, that's expected. I thought in a wrong direction, as I already mentioned. Another thing just to make sure. Try like: --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -882,7 +882,7 @@ int snd_hdac_query_supported_pcm(struct hdac_device *codec, hda_nid_t nid, formats |= SNDRV_PCM_FMTBIT_U8; bps = 8; } - if (val & AC_SUPPCM_BITS_16) { + if (0 /*val & AC_SUPPCM_BITS_16*/) { formats |= SNDRV_PCM_FMTBIT_S16_LE; bps = 16; } so that it kills 16bit format. Other than that, I have no idea, so far. We need to ask Realtek and Intel about such weird behavior.
Disabling S16_LE doesn't help, a 32bit 48khz sample still plays back at 200% with the above patch. Any suggestions where to ask for more info on this issue?
One more sanity check. Try to disable the speaker pin, e.g. creating /lib/firmware/alsa/disable-spk containing the following lines: [codec] 0x10ec0298 0x144dc135 0 [pincfg] 0x14 0x40f000f0 ... then pass it via patch module option to snd-hda-intel, e.g. creating /etc/modprobe.d/50-hda.conf containing options snd-hda-intel patch="alsa/disable-spk" Then you'll have only "Master" control for the headphone. Does it show the same bad speed? I guess so, but really need to check.
With that patch on pin 0x14, nothing changes. However pin 0x17 is headphones, so if I change 0x14 to 0x17 in the patch, the Headphone volume control does indeed disappear but there is no audio output whatsoever. Looking at the time it takes to play the sample though, speed is still at 200%. I also found that playback on the 3 HDMI output devices is at 200% as well. FWIW here's the unpatched dmesg output with increased debugging: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) snd_hda_intel 0000:00:1f.3: bound to i915 component master snd_hda_intel 0000:00:1f.3: display power enable snd_hda_intel 0000:00:1f.3: enable codec wakeup snd_hda_intel 0000:00:1f.3: disable codec wakeup snd_hda_intel 0000:00:1f.3: Capability version: 0x0 snd_hda_intel 0000:00:1f.3: HDA capability ID: 0x2 snd_hda_intel 0000:00:1f.3: Found ML capability snd_hda_intel 0000:00:1f.3: Capability version: 0x0 snd_hda_intel 0000:00:1f.3: HDA capability ID: 0x3 snd_hda_intel 0000:00:1f.3: Found PP capability offset=800 snd_hda_intel 0000:00:1f.3: Capability version: 0x0 snd_hda_intel 0000:00:1f.3: HDA capability ID: 0x1 snd_hda_intel 0000:00:1f.3: Found GTS capability offset=500 snd_hda_intel 0000:00:1f.3: Capability version: 0x0 snd_hda_intel 0000:00:1f.3: HDA capability ID: 0x5 snd_hda_intel 0000:00:1f.3: Found DRSM capability snd_hda_intel 0000:00:1f.3: Capability version: 0x0 snd_hda_intel 0000:00:1f.3: HDA capability ID: 0x4 snd_hda_intel 0000:00:1f.3: Found SPB capability snd_hda_intel 0000:00:1f.3: enable codec wakeup snd_hda_intel 0000:00:1f.3: codec_mask = 0x5 snd_hda_intel 0000:00:1f.3: disable codec wakeup snd_hda_intel 0000:00:1f.3: codec #0 probed OK snd_hda_intel 0000:00:1f.3: codec #2 probed OK snd_hda_codec_realtek hdaudioC0D0: SKU: Nid=0x1d sku_cfg=0x40642245 snd_hda_codec_realtek hdaudioC0D0: SKU: port_connectivity=0x1 snd_hda_codec_realtek hdaudioC0D0: SKU: enable_pcbeep=0x0 snd_hda_codec_realtek hdaudioC0D0: SKU: check_sum=0x00000004 snd_hda_codec_realtek hdaudioC0D0: SKU: customization=0x00000022 snd_hda_codec_realtek hdaudioC0D0: SKU: external_amp=0x0 snd_hda_codec_realtek hdaudioC0D0: SKU: platform_type=0x1 snd_hda_codec_realtek hdaudioC0D0: SKU: swap=0x0 snd_hda_codec_realtek hdaudioC0D0: SKU: override=0x1 snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x17/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 snd_hda_codec_realtek hdaudioC0D0: inputs: snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 snd_hda_codec_realtek hdaudioC0D0: realtek: No valid SSID, checking pincfg 0x40642245 for NID 0x1d snd_hda_codec_realtek hdaudioC0D0: realtek: Enabling init ASM_ID=0x2245 CODEC_ID=10ec0298 snd_hda_codec_realtek hdaudioC0D0: ==> lo_type=2, wired=1, mio=1, badness=0x0 snd_hda_codec_realtek hdaudioC0D0: multi_outs = 17/0/0/0 : 2/0/0/0 (type HP) snd_hda_codec_realtek hdaudioC0D0: out path: depth=3 '02:0c:17' snd_hda_codec_realtek hdaudioC0D0: spk_outs = 1a/0/0/0 : 3/0/0/0 snd_hda_codec_realtek hdaudioC0D0: spk path: depth=3 '03:0d:1a' snd_hda_codec_realtek hdaudioC0D0: ==> Best config: lo_type=2, wired=1, mio=1 snd_hda_codec_realtek hdaudioC0D0: multi_outs = 17/0/0/0 : 2/0/0/0 (type HP) snd_hda_codec_realtek hdaudioC0D0: out path: depth=3 '02:0c:17' snd_hda_codec_realtek hdaudioC0D0: spk_outs = 1a/0/0/0 : 3/0/0/0 snd_hda_codec_realtek hdaudioC0D0: spk path: depth=3 '03:0d:1a' snd_hda_codec_realtek hdaudioC0D0: loopback path: depth=2 '18:0b' snd_hda_codec_realtek hdaudioC0D0: input path: depth=3 '18:23:08' snd_hda_codec_realtek hdaudioC0D0: input path: depth=3 '18:22:09' snd_hda_codec_realtek hdaudioC0D0: input path: depth=3 '12:22:09' snd_hda_codec_realtek hdaudioC0D0: input path: depth=3 '12:24:11' snd_hda_codec_realtek hdaudioC0D0: Enable HP auto-muting on NID 0x17 snd_hda_codec_realtek hdaudioC0D0: Enable auto-mic switch on NID 0x12/0x18/0x0 snd_hda_codec_hdmi hdaudioC0D2: invalid CONNECT_LIST verb 5[1]:0 snd_hda_codec_hdmi hdaudioC0D2: hdmi: haswell: override pin connection 0x5 snd_hda_codec_hdmi hdaudioC0D2: invalid CONNECT_LIST verb 6[1]:0 snd_hda_codec_hdmi hdaudioC0D2: hdmi: haswell: override pin connection 0x6 snd_hda_codec_hdmi hdaudioC0D2: invalid CONNECT_LIST verb 7[1]:0 snd_hda_codec_hdmi hdaudioC0D2: hdmi: haswell: override pin connection 0x7 snd_hda_intel 0000:00:1f.3: display power enable snd_hda_intel 0000:00:1f.3: display power disable input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input20 input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input21 input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input22 input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input23 input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input24 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, polling the codec once: last cmd=0x003f0500 snd_hda_intel 0000:00:1f.3: display power disable
Sorry, I misread your last comment; I retried with pin 0x1a disabled, but again the same result at 200% playback speed. In fact nothing I toggled in hda-analyzer made any difference for playback speed, and I think I toggled everything there at least twice.
Realtek people told me that the pin 0x17 is basically for I2S connection. (And Samsung doesn't support Linux for this device.) Although the codec chip works for both I2S and HD-audio busses, probably it's set up for I2S inconsistently. However, the HDMI output is a different story. IIRC, this should be only over HD-audio link. So the fact that HDMI also plays in a wrong rate implies that the possible cause is rather in the HD-audio controller side.
One more favor: could you check whether the problem persists even if you do playback while running the recording at the same time?
When I disable 0x17 I lose headphone output. Moreover, in the Windows registry pin 12 and 18 are mapped to Mic-In and pin 17 to Headphones, so that matches up. And I really don't find any evidence in Windows that it is I2S controlled; the driver is standard Realtek and no mention of I2S anywhere. But that might not mean anything of course. And yes, the playback rate is 200% even when recording. Not sure where to go from here; I did look at the SoC rt298.c source but no idea where to start. I see this with i2cdetect -l: i2c-3 i2c i915 gmbus dpd I2C adapter i2c-1 i2c i915 gmbus dpc I2C adapter i2c-11 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-8 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-6 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-4 i2c DPDDC-A I2C adapter i2c-2 i2c i915 gmbus dpb I2C adapter i2c-0 smbus SMBus I801 adapter at f040 SMBus adapter i2c-9 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-10 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-7 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-5 i2c DPDDC-C I2C adapter A number of devices are connected to designware buses 6, 7, 10 and 11 (INT3472 INT347F SMO8A80 STH0001 SYNP1234 TOBH1733) but nothing is found on 8 or 9. Looking at the skylake SoC code, it seems to look for INT343A for Realtek codecs and INT3438 for skylake; neither seem to be present. I don't see this from within Windows either. What I do see is that on Windows the Intel SST driver loads a lot of dsp_fw_release_*.bin files. One final clue: there is an INT344B GPIO controller in Windows, which seems to be supported through drivers/pinctrl/intel/pinctrl-sunrisepoint.c and its source seems to have support for SPKR and DMIC_* pins. Is it possible that the speaker GPIO is controlled outside the audio codec?
After some digging I managed to play with the SPKR and I2C[2-5]_* pins on the sunrise point gpio controller, but that did not enable speaker output. It was a long shot anyway. So I'm all out of ideas now, other than that the skylake audio isn't getting initialized correctly (re dsp_fw_*.bin files)
Created attachment 247111 [details] register dump
Could you please apply the register dump patch and send out the dump info of: # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg_dsp # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg_gt # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg_ml # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg_spbf # cat /sys/devices/pci0000:00/0000:00:1f.3/hda_reg_vendor 0000:00:1f.3 may change. You can use lspci -vvv to check it, or check /sys/module/snd_hda_intel/drivers/pci:snd_hda_intel to find it.
Created attachment 247121 [details] Register dump patch output hda_reg* output attached
Created attachment 247201 [details] change em1
Created attachment 247211 [details] change lctl
Could you please apply change em1 patch and test. And then together apply lctl patch and test again? Thanks.
First, I undid the tmp regdump patch. Second, what does not work is em1+lctl: <0>in hda_intel_init_chip 568, em1: 0x1020608 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... Third, with only em1 patch at boot: <0>in hda_intel_init_chip 568, em1: 0x1020608 Playback speed/pitch is still 200% + no speaker output. Finally, when I boot with em1 patch and then do 'alsa unload', set printk to 7 + debugfs +p on sound/*, and then modprobe snd-intel-hda again: [ 109.751295] <0>in hda_intel_init_chip 568, em1: 0x20608 Audio playback speed is then 100% correct! Success! I am a bit puzzled why it needs an additional unload and modprobe to work though?
1. The patch should change em1 register, no only for the unload, but also for the bootup. My platform does the right change when bootup. It's weird... 2. Could you please test revert all patches and only apply the lctl patch?
It will be better that you add the printk to see if the register is changed. In your dump info: in hda_intel_init_chip 568, em1: 0x1020608 It should be the information before we changed. I only add the printk before changing.
1. em1 pre reads the value before writing; post reads it again after writing; at bootup: [ 16.136234] <0>in hda_intel_init_chip 568, em1 pre: 0x1020608 [ 16.136237] <1>in hda_intel_init_chip 572, em1 post: 0x20608 playback is at 200% after alsa unload && modprobe: [ 66.797895] <0>in hda_intel_init_chip 568, em1 pre: 0x20608 [ 66.797902] <1>in hda_intel_init_chip 572, em1 post: 0x20608 playback is correct. Perhaps em1 should be set earlier? 2. With no em1 and only lctl, at bootup: [ 16.141167] <2>in hda_intel_init_chip 575, lctl pre: 0x810000 [ 16.141169] <3>in hda_intel_init_chip 580, lctl post: 0x810003 [ 19.173665] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 [ 20.181376] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 [ 21.189374] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... after alsa unload && modprobe: [ 50.982492] <2>in hda_intel_init_chip 575, lctl pre: 0x810003 [ 50.982493] <3>in hda_intel_init_chip 580, lctl post: 0x810003 Codec stays disabled, no result.
FWIW I did find the datasheet here http://www.intel.com/content/www/us/en/processors/core/6th-gen-core-pch-u-y-io-datasheet-vol-2.html but I am not sure where the documentation is for the registers show in hda_show_vendor; is that the Realtek codec being written to?
OK. Thanks. It seems the lctl patch works on my platform. The registers for vendor is supposed in another spec. I will check with our silicon team about the register setting sequence. Maybe we need a reset for it.
Hello Libin Yang and Infernix, I too have a galaxy tabpro S with Ubuntu (16.04) installed and I just discovered this post and thus upgraded to kernel 4.9-rc2 with the hopes of solving the sound output issue using the eml patch. I've read thru this thread but I can't seem to figure out which file was patched. Was it: snd_hda_intel and how? Thanks in advance for your help! Richard
Hi Richard, The following 2 files will be patched: include/sound/hda_register.h | 1 + sound/pci/hda/hda_intel.c | 4 ++++ You can download the patch and run git am xxx.patch directly in the source code root folder. And after it is compiled, the new snd_hda_intel kernel module will be created. Thanks, Libin
Hi infernix, COuld you please try modify the lctl patch and set val to 0x2 not 0x3: val |= 0x3; == > val |= 0x2； This is used to setting the clk. 0x3 means use 48MHz clk. However I was told 48MHz is not supported. And before setting lctl, EM1.LFLCS is 0, which means we still need em1 patch. Thanks, Libin
Hi Libin, <0>in hda_intel_init_chip 568, em1 pre: 0x1020608 <1>in hda_intel_init_chip 572, em1 post: 0x20608 <2>in hda_intel_init_chip 575, lctl pre: 0x810000 <3>in hda_intel_init_chip 580, lctl post: 0x810002 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... No luck with 0x2 on bootup. Same result with em1 at boot, unload, and then modprobe with em1+lctl: <0>in hda_intel_init_chip 568, em1 pre: 0x1020608 <1>in hda_intel_init_chip 572, em1 post: 0x20608 alsa unload && compile with lctl patch && modprobe <0>in hda_intel_init_chip 568, em1 pre: 0x20608 <1>in hda_intel_init_chip 572, em1 post: 0x20608 <2>in hda_intel_init_chip 575, lctl pre: 0x810000 <3>in hda_intel_init_chip 580, lctl post: 0x810002 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... For reference, code in question: #define AZX_REG_SKL_ML_LCTL 0xC44 #define AZX_REG_SKL_EM1 0x1000 ... val = azx_readl(chip, SKL_EM1); printk("<0>in %s %d, em1 pre: %#x\n", __func__, __LINE__, val); val &= ~0x1000000; azx_writel(chip, SKL_EM1, val); val = azx_readl(chip, SKL_EM1); printk("<1>in %s %d, em1 post: %#x\n", __func__, __LINE__, val); val = azx_readl(chip, SKL_ML_LCTL); printk("<2>in %s %d, lctl pre: %#x\n", __func__, __LINE__, val); val &= ~0xf; val |= 0x2; azx_writel(chip, SKL_ML_LCTL, val); val = azx_readl(chip, SKL_ML_LCTL); printk("<3>in %s %d, lctl post: %#x\n", __func__, __LINE__, val);
Hi infernix, Thanks, it seems it still doesn't support this rate. I will check with our silicon team to see if we need some extra setting.
Created attachment 247781 [details] new change em1
Created attachment 247791 [details] dump register setting
Hi infernix, Please apply new change em1 patch and have a test. Also please apply the dump register setting patch and send me the dmesg. Our silicon is asking for all the register accessing. Our silicon team asked to reset the em1 register in chip reset. However I did the test and it failed to reset the em1 register in reset. So I reset em1 before reset the chip. No sure it will work. Thanks, Libin
Created attachment 247831 [details] new em1 patch with register dump Hi Linbin, At bootup still the same - 200% playback rate. After unload && modprobe playback speed of 48khz (32bit) samples with -Dhw is correct, however playback of 44khz audio with -Dplughw sounds like it gets downsampled to 22khz or less; I don't recall this from the previous em1 patch but it may have been that way already. Additionally, the first time playing any sample has a 1-3 second extra delay before it starts (has always been the case). Full system log attached; you can search for 'Playing WAVE' to find audio playback times.
Hi infernix, It's werid. It seems that you can't change the em1 register at the first time and it is OK for me. Our silicon give me some other advices on it. I will work out patches later today or tomorrow. Thanks, Libin
Created attachment 248231 [details] change em1 v3
Hi infernix, Could you please help try change em1 v3? I try to modify the em1 in 2 ways in this patch: 1. try to modify the shadow em1 2. before change the em1, clear SPA Either one way works will help to fix this issue. Thanks, Libin
Hi Libin, Playback is correct at bootup with -Dhw and 48khz samples! Success :) dmesg: [ 16.125053] <0>in hda_intel_init_chip 589, sem1: 0x1020608 [ 16.125058] <0>in hda_intel_init_chip 589, sem1: 0x20608 [ 16.125059] <0>in hda_intel_init_chip 589, set SPA to 0 and wait CPA to 0 [ 16.224344] <0>in hda_intel_init_chip 589, lctl: 0x10000 [ 16.224347] <0>in hda_intel_init_chip 589, em1: 0x20608 [ 16.224350] <0>in hda_intel_init_chip 589, em1: 0x20608 [ 16.224351] <0>in hda_intel_init_chip 589, set SPA to 1 and wait CPA to 1 [ 16.323634] <0>in hda_intel_init_chip 589, lctl: 0x10000 [ 16.334387] <0>in hda_intel_init_chip 611, sem1: 0x20608 [ 16.334395] <0>in hda_intel_init_chip 611, sem1: 0x20608 [ 16.334396] <0>in hda_intel_init_chip 611, set SPA to 0 and wait CPA to 0 [ 16.433678] <0>in hda_intel_init_chip 611, lctl: 0x0 [ 16.433681] <0>in hda_intel_init_chip 611, em1: 0x20608 [ 16.433682] <0>in hda_intel_init_chip 611, em1: 0x20608 [ 16.433683] <0>in hda_intel_init_chip 611, set SPA to 1 and wait CPA to 1 [ 16.532976] <0>in hda_intel_init_chip 611, lctl: 0x810000 However, playback of 44khz audio with -Dhw as well as -Dplughw still sounds bad, as if being played back with less bits or lower samplerate. This is /proc/asound/card0/pcm0p/sub0/hw_params during playback of 44khz with -Dhw: ./hw_params:access: RW_INTERLEAVED ./hw_params:format: S16_LE ./hw_params:subformat: STD ./hw_params:channels: 2 ./hw_params:rate: 44100 (44100/1) ./hw_params:period_size: 4096 ./hw_params:buffer_size: 16384 And this with -Dhw of 48khz sample: ./hw_params:access: RW_INTERLEAVED ./hw_params:format: S16_LE ./hw_params:subformat: STD ./hw_params:channels: 2 ./hw_params:rate: 48000 (48000/1) ./hw_params:period_size: 4096 ./hw_params:buffer_size: 16384 So as you can see, it does set the hardware to the actual sample rate, but it almost seems it doesn't really support 44khz. 48k, 96k and 192k are all fine with -Dhw. Should we force minimum sample rate to 48k?
Hi infernix, I remember 44.1KHz never works before even with my patches after reloading the snd modules, right? However, 44.1KHz should be supported by HW. Otherwise with -Dplughw, it will be resampled to a correct sample rate. I'm still thinking it may be a clock issue. Could you check the output of /proc/asound/card0/pcm0p/sub0/hw_params with -Dplughw for 44.1KHz? Thanks, Libin
Hi Libin, Hw_params shows playback rate to be 44.1khz with both -Dhw and plughw for 44.1khz samples.
Created attachment 248811 [details] new change v4
Created attachment 248821 [details] select audio pll
Sorry for the delay. I didn't get the suggestion from our silicon for the 44.1KHz issue. I created 2 patches based on my understanding. Could you please apply "new change v4" and do the test? If it doesn't work, could you please help revert the "new change v4" and apply "select audio pll" and do the test? The "select audio pll" doesn't fix the 44.1KHz issue. However, if it works for 48KHz, I will submit the patch to ALSA. THanks, Libin
em1 v4 works at 44.1khz and 48khz with -Dhw, but has audible crackle during playback. 96khz with -Dhw plays it at a speed of 0.5 (e.g. voice is downpitched), and reports "Warning: rate is not accurate (requested = 96000Hz, got = 48000Hz)" so 96khz rate seems unselectable now. Dmesg after boot: <0>in hda_intel_init_chip 600, lctl: 0x810000 <0>in hda_intel_init_chip 600, set SPA to 0 and wait CPA to 0 <0>in hda_intel_init_chip 600, lctl: 0x0 <0>in hda_intel_init_chip 600, lctl: 0x2 <0>in hda_intel_init_chip 600, set SPA to 1 and wait CPA to 1 <0>in hda_intel_init_chip 600, lctl: 0x810002 After unload && modprobe the result is the same. The crackle is pretty weird. It happens only with 16bit samples. As soon as I play a 32bit sample, crackle disappears with all playback (both 16 and 32 bit). I have to power off and on the device to make it return. It might be a fluke. However, select audio pll patch actually has the exact same result as em1 v4 patch. both 44khz and 48khz work fine, and 96khz playback speed is at 0.5. This patch does not appear to have crackle issue. So I suppose that last patch is fine. Not sure why 96khz does not work anymore, but at least this seems to give a valid working result and isn't device specific. Lastly, do you perhaps have any further suggestions for enabling speaker output?
I have to correct the last comment, it seems there is crackle with em1 v3, v4 AND select audio pll patches. I retested with some music and video playback and the crackle is constantly there at 16bit playback with lower volume. It's strongest in the right channel but present in both. I also double checked and it doesn't matter if playback is S16 or S32. Changing volume also does not matter (e.g. it isn't hard clipping); it happens at just about all volume levels, but worst between 30-40% volume. But it is volume dependent - with no sound (e.g. silent/low volume moments in music) there is no crackle. So lowering volume actually makes it worse most of the time. I didn't notice it before since I didn't use good headphones, but it's clearly there.
For 96KHz, I think it is not supported by hardware for this sample rate as it described. You should use -Dplughw to playback 96KHz. For the crackle issue, could you test on HDMI audio to see if HDMI audio is OK. If it is OK for HDMI and only analog audio has crackle issue, I think this should be codec related issue. Otherwise, it should be HDA controller issue. And what do you mean "speaker output", do you mean the speaker doesn't work all the time?
The device only has USB-C out, and I have no USB-C hub with HDMI out. Do you have any suggestions to try? If not I will order something. Speaker output does not work at all, I have been testing using headphone jack only. In the beginning of the bug report I have discussed various options I tried (GPIOs, verbs etc) but nothing worked so far to get speaker output working.
The speaker support is very likely vendor-specific secret, so unfortunately nothing we can help much here remotely. You need to figure out by yourself -- or ask Samsung. FWIW, in addition to GPIO pins, most common tweaks are about VREF of some unused pins. Or... if it's an Android device, you can look for the code somewhere.
It's a windows device, so no luck there. And as i mentioned earlier, I'm not finding any usable info in the windows registry or realtek drivers (they are standard realtek drivers, not Samsung specific), nor are there any .ini files. As far as I can tell Windows treats it as any other realtek card. I'll see what I can find about VREF; any example driver code I can look at? I've ordered a USB-C to HDMI multiport adapter, will update when I have it.
The low volume crackling issue does not exist on HDMI output; however, playback at 44.1kHz over HDMI with -Dhw does sound like it's playing with less bits or lower samplerate (e.g. pitch is correct but audio sounds tinny. So the crackle with low volume issue does seem codec related. I'm not sure why the 44.1khz playback is problematic over HDMI. Should I try to undo the pll patch and try em1 v4 patch?
Thanks for update. Yes, it seems the crackling issue is realteck related. Based on your test before, em1 v4 works at 44.1khz and 48khz with -Dhw. Does this mean only em1 v4 patch is enough for the playback sample rate issue? If so, I will refine the patch and ask our QA do a test on it and submit the patch. For the realtek crackling issue, I thought this may be realtek codec register setting issue. We may need realtek help. Thanks, Libin
As for the rates, in Windows there is the option to choose between 16/24 bit and 44/48/96/192khz as "default format", so I do think the hardware supports it. It is possible that the realtek driver resamples to 48khz right before playback, but then why offer the options? So I assume all of these combinations are supported in hardware, no? As for crackle, on analog out, "em1 v4 patch" was equivalent to "select audio pll patch". I will compare the two patches over HDMI out and see if there is any difference there.
I'm not sure about your first question. From your hw info from codec: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 Both should be supported. If both patches from me works, I will pick up one proper patch to submit. Thanks, Libin
Created attachment 252531 [details] ALSA-hda-set-intel-audio-clock-to-a-properly-value
Hi Infernix, I have refined the patch. Which will be submitted if our QA test passes. Could you please also help test this patch? As we didn't reproduce your issue on our side. Thanks, Libin
The patches is "ALSA-hda-set-intel-audio-clock-to-a-properly-value"
Hi Libin, The new patch on 4.10.0-rc5 does not work at boot time: [ 19.328677] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 [ 20.336666] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 [ 21.344671] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... But works after alsa unload && modprobe: [ 723.956892] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 724.000192] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker [ 724.000194] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 724.000195] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x17/0x0/0x0/0x0/0x0) [ 724.000196] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 724.000197] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 724.000198] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 [ 724.000199] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 It still suffers from crackling audio at low volume levels on headphone out like the last versions. I have not yet retested HDMI at 44kHz. I've also tried again to reach out to Samsung through multiple channels but am not getting anything. Can't get anyone to tell me who to contact to find out how speaker pinout is connected, so I'm afraid I'm at a dead end here.
Hi infernix, Thanks for test. I'm currently on vacation. I will update the patch after my vacation. I'm back on about 2.14. Thanks, Libin
I am using a BT speaker right now, and it's working fine. However, neither the headphone jack nor the built-in speaker works for me. Hope it helps.
Created attachment 254743 [details] ALSA-hda-set-intel-audio-clock V2
Created attachment 254745 [details] add-debug-info v2
Could you please help test "ALSA-hda-set-intel-audio-clock V2". If it doesn't work, please also apply " add-debug-info v2" and send the dmesg. For BT speaker, I think it should not use the HDA Controller and codec.
Hi Libin, Unfortunately at bootup it still fails, but works after a unload & modprobe. Here's the debug info at cold boot: root@tabpro:~# dmesg | egrep '<0>|snd' snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) <0>in intel_init_lctl 577 <0>in intel_init_lctl 581, lctl: 0x810000 <0>in intel_init_lctl 606, lctl: 0x0 <0>in intel_init_lctl 615, lctl: 0x2 <0>in intel_init_lctl 629, lctl: 0x810002 snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000 snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it... And here at unload & modprobe: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) <0>in intel_init_lctl 577 <0>in intel_init_lctl 581, lctl: 0x810002 snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x17/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 snd_hda_codec_realtek hdaudioC0D0: inputs: snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 Crackle at low volume levels is still present as well.
Hi infernix, It's weird. The lctl register is set correctly based on the dmesg. And the error message is caused by no response from codec. The patch is similar with em1 v4. What the difference I can see is that the delay after setting the registers is different. Could you please help add some delay "mdelay(100)" like what em1 v4 patch does? Thanks, Libin
Hi Libin, That seems to fix it: [ 16.296168] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) [ 16.296573] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 16.553826] <0>in intel_init_lctl 577 [ 16.553829] <0>in intel_init_lctl 581, lctl: 0x810000 [ 16.553831] <0>in intel_init_lctl 597, 1. - mdelay(100) after azx_writel: 0x800000 [ 16.653127] <0>in intel_init_lctl 608, lctl: 0x0 [ 16.653131] <0>in intel_init_lctl 616, 2. - mdelay(100) after azx_writel: 0x2 [ 16.752432] <0>in intel_init_lctl 619, lctl: 0x2 [ 16.752435] <0>in intel_init_lctl 625, 4. - mdelay(100) after azx_writel: 0x10002 [ 16.851731] <0>in intel_init_lctl 635, lctl: 0x810002 [ 16.886130] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker [ 16.886132] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.886134] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x17/0x0/0x0/0x0/0x0) [ 16.886135] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 16.886136] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 16.886138] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 [ 16.886139] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 Do you want me to try to read the register before and after the delays?
Created attachment 254771 [details] ALSA-hda-set-intel-audio-clock V3
Hi infernix, So it should be the timing issue. The delay is not required in our spec. Could you please test the "ALSA-hda-set-intel-audio-clock V3" patch? I add 2 udelay(100) in the the code. And I think 100us is also too long. If V3 works, Could you please try to udelay(20) or udelay(50) instead of udelay(100)? And if udelay(100) is not enough, could you please use usleep_range(500, 1000); to wait for more time? Thanks, Libin
Hi infernix, Any update on this bug?
Sorry, I've been quite busy. I will make some time in the next 24h to test.
So the default udelay(100) works. Also tested: - 25: doesn't work - 38: doesn't work - 45: doesn't work - 50: works with reboot, not cold boot - 60: works with reboot and cold boot (tested around 5 times) - 75: works with reboot and cold boot (tested 3 times) I guess 75 is a safe default but if too long, 60 seems fine.
Great! Let make it 100. Suppose it should be acceptable as 50ns is not stable. Thanks.
hi Infernix, If this bug is fixed in your side, please help to close it. Thanks~
Although this patch fixed the skylake initialisation problem causing wrong playback speeds (thank you Libin!), it does not fix the original bugreport: - Speaker output is still not working - Headphone output has audible crackle at low volumes So it wouldn't be accurate to consider this bug fixed and therefore I'd like to keep it open.
The remained 2 bugs are more likely codec related or board related issue (special GPIO?). I think it will be helpful that codec vendor (or board related driver) can help on the 2 issues.
Created attachment 255675 [details] v4 patchset patch1
Created attachment 255677 [details] v4 patchset patch2
Hi infernix, Could you please help test v4 patchset patch1 & patch2? These patches are refined based on the review. BTW: It will be helpful if you can add the Tested-by. Thanks, Libin
Hi Libin, Tested, works from cold boot and reboot.
Hi Infernix, Thanks. I will submit the patches today. Regards, Libin
Hi, Is there any more progress on this (Original bug report) or is anyone else working on it? I have my TabPro S running Arch and it's an awesome setup. Just missing the sound output. Also still have the touchpad issue when removing/attaching the keyboard but I can live with that. Everything else works great, just need sound. Thanks in advance. Talos.
Based on my knowledge on this bug. I think it may be the audio codec (driver) issue. Hope audio codec vendor can help on this.
Libin, any idea how to reach out or involve the audio codec vendor?
I think you can ping pshou@realtek.com.tw
I guess not anymore: <pshou@realtek.com.tw>: host rtittwmx.realtek.com.tw[211.75.126.73] said: 550 Unknown user (in reply to RCPT TO command) Any other suggestions?
You can try: pshou@realtek.com and kailang@realtek.com
Unfortunately I did not get any response from either.
I don't have other contacts.
Deciding whether to buy a used TabPro S.. is it safe to say this bug will not be resolved in the foreseeable future?
I see no way to move this forward, so don't count on it. On July 15, 2018 10:39:59 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=188411 > > robsmith11@yandex.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |robsmith11@yandex.com > > --- Comment #95 from robsmith11@yandex.com --- > Deciding whether to buy a used TabPro S.. is it safe to say this bug will not > be resolved in the foreseeable future? > > -- > You are receiving this mail because: > You reported the bug.