This happens on GPD Pocket laptop details from alsa-info.sh is here: http://www.alsa-project.org/db/?f=f93f3be1ec2f896ba6670d20b6e37f589b44fd10 some more info from log: Jul 13 11:12:17 [pulseaudio] [alsa-sink-1] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. Jul 13 11:12:17 [pulseaudio] [alsa-sink-1] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_soc_sst_cht_bsw_rt5645'. Please report this issue to the ALSA developers. Jul 13 11:12:17 [pulseaudio] [alsa-sink-1] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Just to add to this - I'm experiencing the same problem on the GPD Pocket (more info on device at https://www.indiegogo.com/projects/gpd-pocket-7-0-umpc-laptop-ubuntu-or-win-10-os-laptop--2#/) There has been a lot of work gone in to getting Linux running smoothly on this device and we're just about there! This is the one big remaining issue - audio is silky smooth on Windows and sounds garbage on Linux sadly. I have checked all of the volumes on the device and none are set excessively high. I have also noticed there is a pattern of the audio getting more crackly in line with CPU usage. This may be a coincidence but hopefully at least gives a potential avenue to explore. If you need any additional information at all I'm more than happy to provide it.
@Jaroslav Kysela - if this is in the wrong place - can you point me in the right direction for this issue since it's really holding back enjoying Linux on the device and there doesn't seem to be much appetite for investigating it 'round these parts sadly.
can you remove HDMI audio support for now? there are known issues with pulseaudio w/ HDMI. There are known issues on some rt5645 platforms with the headphone quality but the speakers should work fine.
Hi Pierre, I'll disable the HDMI audio output and see if that makes any difference but I'm fairly sure this has been tested previously and did not resolve the issue. I also wanted to add that currently the PulseAudio (not strictly ALSA I know but may be relevant) realtime-scheduling has to be disabled to get this stuff to work. Sadly we haven't made any developments on the audio situation with the GPD Pocket since: http://hansdegoede.livejournal.com/17445.html Anyway - I will check the audio situation HDMI enabled and report back shortly. Will also try with/without realtime-scheduling to see if that makes any difference - again, not directly ALSA related so may not be of interest to this group.
Ok - here's where I am with this: - I've blacklisted snd_hdmi_lpe_audio and HDMI does disappear from audio output options . No change in audio. - I've turned OFF realtime-scheduling with HDMI disabled. No change in audio. - I've turned ON realtime-scheduling with HDMI disabled. No change in audio. It looks like the 3 tests I tried above had no effect on thi bug. I also tested with both speakers and earphones - the result was the same on both - highly crackly audio. It's the type of distortion you get when speakers are at the very high end of what they can produce *but* this happens even at very low volumes. It also does *not* happen on Windows for me so this is a Linux isolated bug. I have verified that this happens on kernel build 4.13-rc2 (patched - can be seen at: github.com/jwrdegoede/linux-sunxi - various patches added for other GPD Pocket specific issues which are being slowly moved to the mainline kernel.) Hopefully this gives you some more information to work with - I'm more than happy (as I'm sure are others) to experiment with this and provide any debugging information you need - it's really limiting the devices usefulness and would be great to get working properly!
audio quality issues are the worst to debug, since it often depends on non-discoverable properties such as hardware layout, power delivery, etc. Usually progress is made only when the schematics are shared by the vendor. Or devices are provided to Intel/Realtek. Sorry, I know it's not helping much...
@Pierre - thanks for the heads up. Not sounding hopeful so far! What would you advise we do next to get some movement on this? I will happily sink hours in to getting this resolved if necessary - it's such a lovely piece of kit and is being let down by this frustrating issue. If it helps at all - there have been rumours that the CPU usage on the system affects this audio issue. Could be a complete red herring though because audio decoding (and particularly video decoding) is going to stress the chip a bit. The earphones / headphones output has the *exact* same issue too. As noted earlier - this issue does not occur on Windows at reasonable levels of volume (obviously you get a bit of distortion with the volume at max but the same is true for any low budget audio equipment and the speaker in this thing is tiny - not expecting Bang & Olufsen audio quality but this is insufferable.
Hm, when I debug my colleague's GPD Win (not Pocket), we didn't notice such a noise problem. This implies a few possibilities: - GPD Pocket audio is incompatible with GPD Win although we apply the same quirk - Audio routing is incompatible with GPD Win, thus UCM profile needs rewrite - Some stale mixer setup is left (e.g. bogus routing) by some reason For the last point, you can try to unload the all sound modules, remove alsactl sound state (e.g. /var/lib/alsa/asound.state, /etc/asound.state, or else), and reload the sound module again.
What would also be helpful is if someone with a Pocket can test the ubuntu image GPD has recently released and see if that also has the problem, if it does not then you may want to check for an UCM file on there (hoping they are using one and not have something custom) as well as ask them to release their kernel sources to see if they have any audio driver patches.
@Takashi I suspect this is either #1 or #2 - is there any way I can offer useful information on either of these to try and figure this out? Option #3 doesn't seem likely because I've reinstalled the system so many times (clean installs every time) because I'm working on a fully automated system install script (bootstrapping basically) so in the pursuit of perfecting this many reinstalls have been needed. Every time I have completed these and tested the audio I have the exact same problem. What I'm wondering is - is there any information we can extract from a running GPD Win and GPD Pocket and compare the two? Perhaps that would allow us some further clarity in to where the issue is. @Hans - it does have the same issue (very sadly) because: The image doesn't boot *at all* but we've extracted files from the squashfs image and found that there are no changes the audio files at all (not even the realtime-scheduling stuff you added for pulse.) If you still have your GPD Win - perhaps you could lend a hand on the above to see if there are any clear differences between the GPD Pocket and GPD Win hardware.
The official GPD Ubuntu beta firmware have also the crackling noise on my GPD Pocket. For completeness i attach alsa-info.sh taken from a full boot on that system, using their kernel "4.12-rc2+". http://www.alsa-project.org/db/?f=6340c2ae0f5277646dadcf6ad93e87812e8b78a2 My crackling noise is also not that insufferable. Is just a little background noise and it sounds like the background noise of a bonfire. Weak but is there and you can hear it sometimes clearly. Headphones are working on that kernel "4.12-rc2+" and also suffer of the same problem. UCM file is the same of plbossart repository: https://github.com/plbossart/UCM/blob/master/chtrt5645/HiFi.conf
So where do we go from here? - GPD don't seem like they're going to fix this any time soon. - Even with the absolute latest kernel commit this issue persists. The only other thing I can think of to do is tweak all of the settings available in alsamixer but there's a LOT and I'm not really sure what I'm tweaking. Any pointers or would this be a waste of time?
Well, the true is that nobody really submitted anything for GPD Pocket *at all*. It's a pure luck that it worked somehow in a compatible way as GPD Win. So, someone who has GPD Pocket has to try some adjustment via trial-and-error by themselves.
Ok - I've done some experimentation on this and found that two things are true which may be helpful to resolve this issue. 1.) There is *no* right speaker output on my device - I assume this is true for all GPD Pockets so this is clearly mono output device (though shows stereo in alsamixer.) 2.) The crackling / static noise seems to occur in line with CPU/GPU usage - i.e. if I frantically move the mouse it happen a LOT - if I just leave it be it happens very rarely so my theory on this is that there is some kind of interference from CPU/GPU usage. On point #2 - this is a strange one since usually I would chalk this up to hardware but the same static doesn't occur on Windows so I'm a bit at a loss on this one. If this does not provide anything useful for you - if someone could point me in the right direction on what I should be experimenting with to diagnose this that would be great! Thanks all.
Hi, There are some interesting differences between the upstream sound/soc/codecs/rt5645.c and the one in the kernel GPD just released for the pocket: --- sound/soc/codecs/rt5645.c 2017-07-21 22:28:48.016248040 +0200 +++ /home/hans/rt5645.c 2017-08-18 09:58:12.909433600 +0200 @@ -70,7 +59,7 @@ static const struct reg_sequence init_list[] = { {RT5645_PR_BASE + 0x3d, 0x3600}, - {RT5645_PR_BASE + 0x1c, 0xfd70}, + {RT5645_PR_BASE + 0x1c, 0xfd20}, {RT5645_PR_BASE + 0x20, 0x611f}, {RT5645_PR_BASE + 0x21, 0x4040}, {RT5645_PR_BASE + 0x23, 0x0004}, @@ -3779,8 +3752,6 @@ ret); } - regmap_update_bits(rt5645->regmap, RT5645_CLSD_OUT_CTRL, 0xc0, 0xc0); - if (rt5645->pdata.in2_diff) regmap_update_bits(rt5645->regmap, RT5645_IN2_CTRL, RT5645_IN_DF2, RT5645_IN_DF2); (note copy and pasted manually to only get the interesting non hacky parts of the diff, you will need to apply this manually). Might be interesting to see if these 2 changes fix the crackling.
re #15 The patch is for speaker protection. I don't think it is related to the crackling issue.
I'll build a kernel with that patch in place Hans and report back if there's any difference. If what @Bard reports is true - it doesn't sound hopeful but hey - given the absence of any other ideas at the moment it's worth a shot!
Hmm, thinking more about this, the crackling could be simple buffer under-runs somewhere in the pipe, they do sound a bit like this (from previous experience doing sound work in games) and the pocket is using a 1920x1200 screen where as the win has a 1280x720 screen so the display engine is using more bandwidth to driver the panel and this could be interfering with audio-playback. So I did this: echo autospawn = no >> ~/.pulse/client.conf killall pulseaudio LANG=C pulseaudio -vvvv > ~/pulseverbose.log Then at startup I get: I: [alsa-sink-1] alsa-sink.c: Underrun! I: [alsa-sink-1] alsa-sink.c: Increasing wakeup watermark to 28.38 ms And then play some audio then sometime after starting the audio playing (1-2 seconds in) I get: D: [alsa-sink-1] alsa-sink.c: Wakeup from ALSA! D: [alsa-sink-1] alsa-sink.c: Wakeup from ALSA! E: [alsa-sink-1] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. E: [alsa-sink-1] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_soc_sst_cht_bsw_rt5645'. Please report this issue to the ALSA developers. E: [alsa-sink-1] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. D: [alsa-sink-1] alsa-sink.c: Wakeup from ALSA! D: [alsa-sink-1] alsa-sink.c: Wakeup from ALSA! D: [alsa-sink-1] alsa-sink.c: Wakeup from ALSA! And a lot more of the "Wakeup from ALSA!" messages. And on closing the audio playing app (totem) I get: D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink becomes idle, timeout in 5 seconds. D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) D: [alsa-sink-1] sink.c: alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645_0__sink: Found underrun 17028 bytes ago (252 bytes ahead in playback buffer) With the last line repeating about 20 times or so.
If I've to guess this seems to be some free space reporting issue in the sst code which causes pulseaudio to not increase its wakeup latency futher and the 28ms is ends up using is not enough ? Is there a way to override the pa wakeup latency (so that we can test this) ?
Well, to check whether it's an issue of PA or not, you can try native ALSA API, e.g. pasuspender -- aplay -Dplughw foo.wav You can add an option like --buffer-size=524288 in addition to specify the buffer size. If it works even with a shorter buffer, you may try PA with tsched=0 (look at the web search about it).
yes please check without PulseAudio. I've seen occasionally a 'wake-up from ALSA' message but never anything related to interrupts. Also disable the hdmi output if you are using pulse audio, it's still not fixed.
(In reply to Takashi Iwai from comment #20) > Well, to check whether it's an issue of PA or not, you can try native ALSA > API, e.g. > pasuspender -- aplay -Dplughw foo.wav > > You can add an option like --buffer-size=524288 in addition to specify the > buffer size. If it works even with a shorter buffer, you may try PA with > tsched=0 (look at the web search about it). I did grab a WAV and tested - I didn't hear any issues in playback after a few play throughs of a 20sec (or so) clip. I would usually have popping sounds by now so this issue does appear to be between the driver and Pulseaudio. As for --buffer-size, the lowest I could go with this is 440 without causing severe distortion of the audio. Sadly - the tsched=0 fix being added to /etc/pulse/default.pa didn't resolve the issue.
Double-check the pulseaudio log whether tsched=0 really takes effect. The configuration of PA is often tricky.
@Takashi - I have checked the logs and do see a reference to tsched so it does appear that it takes effect (though I am certainly no PA expert.) Not really sure what I should be trying next but I greatly appreciate the assistance so far. Apologies for the delay in responding - busy few days!
I would like to follow up on this issue. I also experienced the crackling noise, albeit on my GPD Win. After investigating PA and ALSA to no avail, last weekend, after some quite extensive bisecting of my .config I was able to narrow down on the issue: For reasons unknown to me the CONFIG_INTEL_ATOMISP=y config setting is interfering with the sound output. IRQ timing issues perhaps? Sound output with CONFIG_INTEL_ATOMISP=n is on par with what I experienced on Windows, i.e. the occasional pop in the sound, but no "bonfire"-esque sound like before. FWIW neither the GPD Win nor the GPD Pocket have an integrated camera module, so there is no need for the ISP/MIPI stuff on these platforms. Most kernels for the GPD Win/Pocket are based on the .config in Hans De Goede's custom kernels which have CONFIG_INTEL_ATOMISP enabled by default. Perhaps somebody can verify this independently or chime in on what else might be the cause?
Created attachment 258783 [details] attachment-31529-0.html I am currently out of office and will return on Oct. 12. Slow mail response may be expected. Please contact shumingf@realtek.com or flove@realtek.com for urgent case. Thanks.
(In reply to Andre H. Beckedorf from comment #25) > I would like to follow up on this issue. I also experienced the crackling > noise, albeit on my GPD Win. After investigating PA and ALSA to no avail, > last weekend, after some quite extensive bisecting of my .config I was able > to narrow down on the issue: For reasons unknown to me the > CONFIG_INTEL_ATOMISP=y config setting is interfering with the sound output. > IRQ timing issues perhaps? > Sound output with CONFIG_INTEL_ATOMISP=n is on par with what I experienced > on Windows, i.e. the occasional pop in the sound, but no "bonfire"-esque > sound like before. FWIW neither the GPD Win nor the GPD Pocket have an > integrated camera module, so there is no need for the ISP/MIPI stuff on > these platforms. > Most kernels for the GPD Win/Pocket are based on the .config in Hans De > Goede's custom kernels which have CONFIG_INTEL_ATOMISP enabled by default. > Perhaps somebody can verify this independently or chime in on what else > might be the cause? Too bad you lost time on this, it's a known issue in the atom ISP driver that is already fixed. see https://lkml.org/lkml/2017/9/22/40
Thank you for the clarification! I saw your patches shortly after posting my reply and figured there might be a connection to this issue here. I guess if chrisaw can confirm that it fixes it, this bug can probably be closed.
(In reply to Andre H. Beckedorf from comment #25) > I would like to follow up on this issue. I also experienced the crackling > noise, albeit on my GPD Win. After investigating PA and ALSA to no avail, > last weekend, after some quite extensive bisecting of my .config I was able > to narrow down on the issue: For reasons unknown to me the > CONFIG_INTEL_ATOMISP=y config setting is interfering with the sound output. > IRQ timing issues perhaps? > Sound output with CONFIG_INTEL_ATOMISP=n is on par with what I experienced > on Windows, i.e. the occasional pop in the sound, but no "bonfire"-esque > sound like before. FWIW neither the GPD Win nor the GPD Pocket have an > integrated camera module, so there is no need for the ISP/MIPI stuff on > these platforms. > Most kernels for the GPD Win/Pocket are based on the .config in Hans De > Goede's custom kernels which have CONFIG_INTEL_ATOMISP enabled by default. > Perhaps somebody can verify this independently or chime in on what else > might be the cause? I can confirm this fixes it on my GPD Pocket. Also using Han's repo and set the ATOMISP to n (Arch Linux)
Hi All, Andre, thank you for figuring out that the atomisp driver was causing the crackling noise, that was very helpful. For me disabling the atomisp driver did not help, as it does not even get loaded on my pocket. So this may be BIOS version / settings specific. If you've a GPD win / pocket then there should NOT be a 8086:22b8 device in the output of lspci -n, as these devices do not have a camera. If you do see this device and you've an unlocked BIOS then you can stop the atomisp driver from needlessly loading by changing the "Chip Set -> North Bridge -> Intel IGD Configuration -> ISP Enable/Disable" setting in the BIOS to "Disabled". Eitherway I've added the patches fixing the atomisp issue to my git repo. For me, since I don't even have the atomisp driver getting loaded, this unsurprisingly did not help. But Andre's info did help me find a way to fix this, the cht-bsw-rt5645 driver has code to configure and enable/disable the pmc_plt_clk_3 clock but that was only active on Bay Trail. It seems that at least my BIOS version is not initializing pmc_plt_clk_3 properly, causing the crackling noise. So I've written a small patch to make the cht-bsw-rt5645 driver also configure pmc_plt_clk_3 on Cherry Trail and the crackling is gone. I've added this patch to my git-repo, I will also submit it upstream and attach it here. Regards, Hans
Created attachment 258825 [details] [PATCH] ASoC: cht-bsw-rt5645: Also enable/disable the clock on Cherry Trail
(In reply to Hans de Goede from comment #31) > Created attachment 258825 [details] > [PATCH] ASoC: cht-bsw-rt5645: Also enable/disable the clock on Cherry Trail This was already merged by Mark Brown, devm_clk_get() is called unconditionally without a test for Baytrail, which was made possible since we don't stop the clock if it's managed by the BIOS. Could you also test if your DSDT contains the CLK3 (or CLK_3) resource, it's usually how this clock is managed. It's the first time i hear a report of the clock not working on Cherrytrail.
Good to know that this is already fixed. My DSDT does have the CLK3 resource, I think the problem is not that it was not enabled (I would expect complete silence then) but that it did not get programmed to the correct clock-rate.
that's odd. can you share the DSDT ? On CHT there is a single 19.2 MHz clock available - no 25MHz - so if the BIOS did not set the correct rate then windows would not work either.
(In reply to Pierre Bossart from comment #34) > that's odd. can you share the DSDT ? On CHT there is a single 19.2 MHz clock > available - no 25MHz - so if the BIOS did not set the correct rate then > windows would not work either. I've put a copy here: https://fedorapeople.org/~jwrdegoede/gpd-pocket-dsdt.dsl One thing which is interesting is that there is a CHAN package in there, which currently the cht-bsw-rt5645 only parses for Bay Trail CR devices. The CHAN packages says the clock should be 19.2 MHz. Note I'm not sure that the clock freq being wrong was the issue that is just a theory. What I did / observed was: 1) Read about atomisp patch, build a new kernel with that patch 2) Boot GPD pocket check if it loads the atomisp module at all -> no Note the drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c file is always builtin, so maybe it was still doing something, but I think it just exports symbols. Still crackling sound at this point 3) Boot new kernel with patches atomisp Still crackling sound at this point 4) Look at cht-bsw-rt5645 code, write patch, boot into kernel with patch Sound is now good (I had one pop during the start of playing some music once) Also even with the patch to also get and control the mclk on CHT, I still got the crackling sound back once while directly manipulating some codec registers to try and get both channels to play through to the single speaker the device has.
Thanks for your hard work Hans. I am only tester and my kernel experience is only from compiling. But I want share my results. I am using GPD Pocket from second branch and Ubuntu 16.04 witch Stockmind setup. I tryed build your kernel (after today commit silead_ts_capacitive_homebut_fixup - 248caea67702042a27eca083a33a6a518ac76c14). I made version witch enable and disable atomisp. Version witch enabled driver is affected - noise and cracking in audio. But if i disable atomisp driver, sound from speaker is perfect (HW limitation, 100% is impossible with nice sound, but 100% volume have not noise in sound). But If I using headphones, I still have problem with unplugging headphone jack( https://www.youtube.com/watch?v=EHwxr4LRVa0 setup before yesterday automatic headphones switch, not sound is switched to speaker, acpi event: headphones unplug). But If i set only correct volume 0-80% I haven't issue witch audio. If I set over and i get unplug I still can restart pulseaudio and got good state without issue.
And second broken state is after resume from suspend. After it, I must restart pulseaudio.
Actually, temporary fix is change value for max volume in usr/share/alsa/ucm/chtrt5645/HiFi.conf from 31 to 25. You still can use SW volume over 100% in pulseaudio settings or VLC for example). cset "name='Headphone Playback Volume' 25"