[alsa-devel] ALC892 acquisition stutter

[rodomar705 at protonmail.com]

Maybe, just maybe, I found a probable cause of what's happening here. Since it was working with ALSA directly only with audacity, I follow the instruction on tracing the HDA commands sent to the codec while acquiring audio with Audacity. One with ALSA directly (just with Audacity thought, arecord show the same problem from Pulse), when is working correctly, one without it, using pulse. The logs are very interesting.

The working one just simply sent two command to the audio codec, and then the stream started.

The other one spammed a lot of more data, and it appears that the problem (and the continuous popping of the audio) derives from the fact that the codec keep closing the stream after 100 to 300 ms, that force pulse to ask the audio controller to restart the stream and cause an actual noise coming from the microphone (since the stream is not instantly restarted).

There is another little difference beetween the second command sent to the codec directly with ALSA (from audacity) and the command sent from Pulse:

ALSA with Audacity:
1106.051129: hda_send_cmd: [0000:09:00.3:0] val=0x00820031
Pulse with Audacity:
1231.103757: hda_send_cmd: [0000:09:00.3:0] val=0x00820011

However with arecord -d 10 -fS16_LE -r44100 /tmp/test-mic.wav as a parameter I still get almost the same as Pulseaudo:

arecord with Audacity:
2891.230874: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
However, no start stop behaviour like on pulseaudio, however the audio clicking are still there.
The log are attached to this email, hoping that will help fix the issue.

Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Il domenica 28 aprile 2019 10:52, <rodomar705 at protonmail.com> ha scritto:

> Already sent to alsa-user, however a developer asked to send this also on devel, so here it is:
>
> I have audio stutters with an ALC892 Realtek Chipset on a B450 GAMING ELITE board from Gigabyte during acquisition (at least with microphone input, both front and back. Line in not tested). No issues with Windows.
>
> After opening an issue and testing with a PulseAudio developer, he has determined that the issue is not within PulseAudio, but on ALSA.
>
> There are already two issues about that on the bug tracker on Linux, namely this two:
>
> ALC892: https://bugzilla.kernel.org/show_bug.cgi?id=203351
> ALC1220: https://bugzilla.kernel.org/show_bug.cgi?id=195303
>
> To me both appears to be identical, for this reason even if I have a ALC892 I’ve posted on the second one, just because it had more posts.
>
> The particular thing is that acquiring with PulseAudio on Audacity show the problem, however using ALSA directly the issue is not present. Trying using arecord still present the issue from PulseAudio.
>
> Tried to play with the parameters /sys/devices/audio to no avail. Compared the pinconfigs from Windows, they are identical.
>
> Can someone try to help me fix the issue?
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsaaudacitylog
Type: application/octet-stream
Size: 986 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190428/c7b8de0c/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulseaudacitylog
Type: application/octet-stream
Size: 17388 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190428/c7b8de0c/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arecordlog
Type: application/octet-stream
Size: 987 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190428/c7b8de0c/attachment-0005.obj>