Re: [alsa-devel] ALC892 acquisition stutter
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@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.
On Sun, 28 Apr 2019 11:34:34 +0200, rodomar705@protonmail.com wrote:
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.
Basically there can be three or four different parameters that may bring difference easily. The most suspected ones are the sample rates and the sample formats. So, check the combination of -fS16_LE, -fS32_LE, -r44110 and -r48000 with arecord. At best, pass -Dhw:0 option (or hw:1, depending on the machine) to assure that no conversion is done in alsa-lib, and pass -c2 option for stereo.
arecord -Dhw:0 -c2 -fS32_LE -r44100 foo.wav
The next would be to check the period size and buffer size. You can specify them via --period-size and --buffer-size options of arecord. They are in frames unit, not in bytes. Try to use a small and a large period / buffer size to see whether they give any difference.
Also, for PA side, you can try the following: - Disable timer-scheduling: if the HD-audio controller is buggy and the pointer updates aren't accurate, it's a problem with the timer scheduling mode used as default in PA. You can pass tsched=0 option somehow, see the PA documentation.
- Try to *not* load Realtek codec driver but use the generic codec driver. For that, pass model=generic option to snd-hda-intel module. (If there are two HD-audio controllers, pass model=generic,generic instead.)
- Try to disable snooping in HD-audio driver, pass snoop=0 option to snd-hda-intel module. I don't think this would matter, but it's been often a problem on a new chip on AMD or other platforms.
HTH,
Takashi
Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Il domenica 28 aprile 2019 10:52, rodomar705@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.
[2 alsaaudacitylog <application/octet-stream (base64)>]
[3 pulseaudacitylog <application/octet-stream (base64)>]
[4 arecordlog <application/octet-stream (base64)>]
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (2)
-
rodomar705＠protonmail.com -
Takashi Iwai