Bugzilla – Bug 1212081
Teams and Zoom sound from computer speaker chops
Last modified: 2023-06-15 21:29:45 UTC
Using both Teams and Zoom on Chrome Browser the speaker sound chops-up to the point that it becomes intelligible and I'm unable to understand the speaking person at all ... the other person hears me clearly ... the issue is not present if I use headphones ... so it might be the noise cancellation between speaker and microphone? ... I have a new installation of Tumbleweed 6.3.4-1-default/KDE Plasma 5.27.5 on a new computer ... this issue was present on my old computer with Tumbleweed o/s as well but seems to be exacerbated on my new laptop
Yeah, it appears to be some echo/noise cancellation, and I guess that's rather implementations in Teams and Zoom themselves. Do you have other applications that show the similar behavior?
(In reply to Takashi Iwai from comment #1) > Yeah, it appears to be some echo/noise cancellation, and I guess that's > rather implementations in Teams and Zoom themselves. > > Do you have other applications that show the similar behavior? Hi Takashi ... yes, it happens with YouTube too ... and of course totally disrupts the ability to peacefully view videos .. but it doesn't happen playing a local music video on VLC or a song on WebSpotify
OK, then it can be some different issue. Could you give alsa-info.sh output? Run the script with --no-upload option and attach the output. Also, try to check whether it has any influence if you mute the Capture mixer switch. If it happens for the playback-only case like YouTube, it's no noise cancellation, but something else.
Created attachment 867445 [details] alsa info
(In reply to Stuart Nettleton from comment #4) > Created attachment 867445 [details] > alsa info The Capture F4 in alsamixer makes not difference if set at 20 or 0
The next step would be to reproduce with basic applications like aplay and without pipewire. I suppose you're using pipewire, and JACK isn't running, right? Check at first whether the issue is seen with simple aplay invocation for long samples. If it appears, try to play without pipewire, e.g. % systemctl --user stop wireplumber % aplay -Dplughw:0 -vv somefile.wav ... % systemctl --user start wireplumber
As you suggest ... pipewire, pipewire-pulse and wireplumber are running ... no Jack service ... chopping occurs when playing a wav file with aplay ... although stopping wireplumber results in "No Output Device" ... the audio is still present with the command "aplay -Dplughw:0 -vv somefile.wav" and the wav file plays without any chopping ... starting wireplumber and the chopping returns
OK, then please check the conditions shown in /proc/asound/card0/pcm0p/sub0/hw_params during playback via pipewire. Then, stop wireplumber, and try to play via aplay with the similar parameters. e.g. aplay -vv -Dplughw:0 --buffer-size=xxxx --period-size=xxxx foo.wav If the format differs (16 vs 32bit format), you can convert the WAV file via sox, for example, too. Also, could you give the dmesg output?
1. This is the result in /proc/asound/card0/pcm0p/sub0/hw_params during playback via pipewire with the command aplay -vv PinkPanther60.wav access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 32768 2. After stopping pipewire with systemctl --user stop wireplumber ... this is the result in /proc/asound/card0/pcm0p/sub0/hw_params with the command aplay -vv -Dplughw:0 --buffer-size=32768 --period-size=1024 PinkPanther60.wav access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 2048 buffer_size: 65536 3. This is what aplay reports in the command window: Playing WAVE 'PinkPanther60.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono Plug PCM: Rate conversion PCM (44100, sformat=S16_LE) Converter: libspeex (builtin) Protocol version: 10003 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 22050 exact rate : 22050 (22050/1) msbits : 16 buffer_size : 32768 period_size : 1024 period_time : 46439 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 1024 period_event : 0 start_threshold : 32768 stop_threshold : 32768 silence_threshold: 0 silence_size : 0 boundary : 2305843009213693952 Slave: Route conversion PCM (sformat=S16_LE) Transformation table: 0 <- 0 1 <- 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 65536 period_size : 2048 period_time : 46439 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 2048 period_event : 0 start_threshold : 65536 stop_threshold : 65536 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 Slave: Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 65536 period_size : 2048 period_time : 46439 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 2048 period_event : 0 start_threshold : 65536 stop_threshold : 65536 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 4. dmesg output attached as dmesg.txt
Created attachment 867512 [details] dmesg output
Try to convert PinkPanther60.wav to 32bit format 48kHz, e.g. % sox PinkPanther60.wav -b 32 -r 48000 test.wav And play it like % aplay -vv -Dplughw:0 --period-size=1024 --buffer-size=32768 test.wav Does it sound still normally?
After converting PinkPanther60.wav to 32bit format 48kHz, with sox PinkPanther60.wav -b 32 -r 48000 test.wav ... the sound becomes very choppy again with aplay -vv -Dplughw:0 --buffer-size=32768 --period-size=1024 test.wav
OK, and how about the 16 bit format? i.e. sox PinkPanther60.wav -b 16 -r 48000 test.wav aplay -vv -Dplughw:0 --period-size=1024 --buffer-size=32768 test.wav
Also, you can try to convert to 44100Hz instead of 48000Hz, and check whether it shows the same bad output or not. Adjust the other parameter values (e.g. decrease the buffer size) would be interesting, too.
Here are the results of sampling and buffer combinations: 1. Original 48000 and buffer 32768 1.1. 32bit test1.wav chopping 1.2. 16bit test4.wav chopping 2. With 48000 and buffer 16384 2.1. 32bit test1.wav chopping 2.2. 16bit test4.wav chopping 3. With 44100 and buffer 32768 3.1. 32bit test2.wav no chopping 3.2. 16bit test3.wav no chopping 4. With 44100 and buffer 16384 4.1 32bit test2.wav no chopping 4.2 16bit test3.wav no chopping
Interesting, I didn't expect chopping with 16bit samples. Could you verify whether a larger period size changes the behavior on 48khz?
Here are the results of sampling and period-size combinations with buffer 32768: 1. Original 48000 and period-size 1024 1.1. 32bit test1.wav chopping 1.2. 16bit test4.wav chopping 2. With 48000 and period-size 2048 2.1. 32bit test1.wav chopping 2.2. 16bit test4.wav chopping 3. With 44100 and period-size 1024 3.1. 32bit test2.wav no chopping 3.2. 16bit test3.wav no chopping 4. With 44100 and period-size 2048 4.1 32bit test2.wav no chopping 4.2 16bit test3.wav no chopping Additional 5. With 48000, buffer 16384 and period-size 2048 5.1. 32bit test1.wav chopping 5.2. 16bit test4.wav chopping Thanks
Then the conclusion is that the playback with 48kHz is *always* choppy no matter which buffer and period sizes are used? That is, a playback without --period-size and --buffer-size option shows the same issue? % aplay -Dplughw:0 -vv some-48k-samples.wav If so, the workaround would be to fix at 44.1kHz, but it's of course no ideal solution, and we need to check further what's wrong. Supposing the problem being in the HD-audio controller: Booting with snd_hda_intel.snoop=1 option makes any difference? Or, how about snd_hda_intel.position_fix=1 boot option? OTOH, if it's about the HD-audio codec, try to boot with snd_hda_intel.model=generic boot option. This might lose some Realtek-specific functionality, but hopefully the speaker can keep working.
(In reply to Takashi Iwai from comment #18) > Then the conclusion is that the playback with 48kHz is *always* choppy no > matter which buffer and period sizes are used? That is, a playback without > --period-size and --buffer-size option shows the same issue? > % aplay -Dplughw:0 -vv some-48k-samples.wav Yes, 48kHz is *always* choppy (its where we started the investigation) > If so, the workaround would be to fix at 44.1kHz, but it's of course no > ideal solution, and we need to check further what's wrong. > > Supposing the problem being in the HD-audio controller: > Booting with snd_hda_intel.snoop=1 option makes any difference? > Or, how about snd_hda_intel.position_fix=1 boot option? Neither of the above boot options made any difference to choppy sound > OTOH, if it's about the HD-audio codec, try to boot with > snd_hda_intel.model=generic boot option. This might lose some > Realtek-specific functionality, but hopefully the speaker can keep working. The above boot option set the Output device to Headphones Thanks
(In reply to Stuart Nettleton from comment #19) > > OTOH, if it's about the HD-audio codec, try to boot with > > snd_hda_intel.model=generic boot option. This might lose some > > Realtek-specific functionality, but hopefully the speaker can keep working. > > The above boot option set the Output device to Headphones Hm, I thought it could give still two selectable outputs. Could you give alsa-info.sh output from that state?
Created attachment 867530 [details] alsa-info file #2
Uploaded alsa-info file with boot option snd_hda_intel.model=generic Thanks (In reply to Stuart Nettleton from comment #21) > Created attachment 867530 [details] > alsa-info file #2
Something went wrong due to the HDMI codec. It doesn't work with the generic parser, so it should be disabled. Could you try to pass snd_hda_intel.probe_mask=0x01 in addition?
(In reply to Takashi Iwai from comment #23) > Something went wrong due to the HDMI codec. It doesn't work with the > generic parser, so it should be disabled. > > Could you try to pass snd_hda_intel.probe_mask=0x01 in addition? With boot option snd_hda_intel.probe_mask=0x01 the sound is choppy (both using aplay -vv -Dplughw:0 --buffer-size=32768 --period-size=1024 test1.wav and YouTube) Thanks
Thanks. Then I have no other idea. Looking at the current driver code, it seems that there is already a quirk for this device (SSID 1558:d502 "Clevo PD50SNE"). I'll try to ping those people who submitted the patch.
They suggested to look for the BIOS update. Could you try that?
(In reply to Takashi Iwai from comment #26) > They suggested to look for the BIOS update. Could you try that? I have completed the latest bios update ... however, its a bit confusing whether the update did its job ... although the update reported success of a new version, my bios still reports the previous version ... in any case, the 48kHz choppy sound problem still exists
It's a pity that it didn't fix. Basically this is a BIOS bug. There is a speaker amp behind the HD-audio codec, and it's BIOS's task to initialize it properly. You can try to set up pipewire config to enforce 44.1kHz as a workaround.
(In reply to Takashi Iwai from comment #28) > It's a pity that it didn't fix. Basically this is a BIOS bug. There is a > speaker amp behind the HD-audio codec, and it's BIOS's task to initialize it > properly. > > You can try to set up pipewire config to enforce 44.1kHz as a workaround. Takashi ... please keep this bug open and I'll notify the fix ... thanks for your great efforts ... cheers, Stuart
(In reply to Takashi Iwai from comment #28) > It's a pity that it didn't fix. Basically this is a BIOS bug. There is a > speaker amp behind the HD-audio codec, and it's BIOS's task to initialize it > properly. > > You can try to set up pipewire config to enforce 44.1kHz as a workaround. Takashi ... upgraded the Bios once again and sound no longer choppy ... many thanks, Stuart