* Re: ALC892 acquisition stutter
@ 2019-04-28 9:34 rodomar705
2019-04-29 15:06 ` Takashi Iwai
0 siblings, 1 reply; 5+ messages in thread
From: rodomar705 @ 2019-04-28 9:34 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, pshou, kailang
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
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.
[-- Attachment #2: alsaaudacitylog --]
[-- Type: application/octet-stream, Size: 986 bytes --]
# tracer: nop
#
# entries-in-buffer/entries-written: 6/6 #P:12
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
audacity-3345 [002] .... 1106.043664: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
audacity-3345 [002] .... 1106.043728: hda_get_response: [0000:09:00.3:0] val=0x00004011
audacity-3345 [002] .... 1106.051129: hda_send_cmd: [0000:09:00.3:0] val=0x00820031
audacity-3345 [002] .... 1106.051183: hda_get_response: [0000:09:00.3:0] val=0x00000000
audacity-3437 [000] d..3 1106.101642: snd_hdac_stream_start: stream_tag: 1
audacity-3437 [011] d..3 1110.250899: snd_hdac_stream_stop: stream_tag: 1
[-- Attachment #3: pulseaudacitylog --]
[-- Type: application/octet-stream, Size: 17388 bytes --]
# tracer: nop
#
# entries-in-buffer/entries-written: 184/184 #P:12
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
audacity-3345 [002] .... 1106.043664: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
audacity-3345 [002] .... 1106.043728: hda_get_response: [0000:09:00.3:0] val=0x00004011
audacity-3345 [002] .... 1106.051129: hda_send_cmd: [0000:09:00.3:0] val=0x00820031
audacity-3345 [002] .... 1106.051183: hda_get_response: [0000:09:00.3:0] val=0x00000000
audacity-3437 [000] d..3 1106.101642: snd_hdac_stream_start: stream_tag: 1
audacity-3437 [011] d..3 1110.250899: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.093671: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.093743: hda_get_response: [0000:09:00.3:0] val=0x00000031
alsa-source-ALC-1288 [003] .... 1231.103757: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [003] .... 1231.103814: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.103834: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.117193: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.118043: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.118082: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [003] .... 1231.127070: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [003] .... 1231.127126: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.127144: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.151408: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.151856: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.151895: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [003] .... 1231.160402: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [003] .... 1231.160458: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.160477: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.172149: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.172710: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.172747: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [003] .... 1231.180413: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [003] .... 1231.180462: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.180489: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.192388: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.192876: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.192914: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [003] .... 1231.203731: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [003] .... 1231.203768: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.203789: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.216294: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.216876: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.216914: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [003] .... 1231.223736: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [003] .... 1231.223792: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.223808: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [003] d..3 1231.236272: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [003] .... 1231.236856: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [003] .... 1231.236893: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [003] .... 1231.243734: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [003] .... 1231.243791: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [003] d..3 1231.243807: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.267787: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.268420: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.268480: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.277079: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.277126: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.277153: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.289439: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.290106: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.290143: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.297067: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.297122: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.297141: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.309698: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.310230: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.310269: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.317074: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.317124: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.317137: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.328930: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.329376: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.329414: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.340399: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.340437: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.340451: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.352498: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.353064: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.353102: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.360400: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.360456: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.360473: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.372707: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.373209: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.373255: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.380402: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.380458: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.380475: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.392404: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.392897: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.392935: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.400405: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.400460: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.400476: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.412727: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.413210: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.413255: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.420400: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.420466: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.420479: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.444714: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.445230: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.445276: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.453733: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.453779: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.453798: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.478411: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.479191: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.479252: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.487078: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.487127: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.487154: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.499429: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.500001: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.500040: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.507071: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.507128: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.507144: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.520538: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.521482: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.521543: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.533730: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.533776: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.533793: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.546221: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.546774: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.546836: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.553733: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.553790: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.553807: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.566046: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.566584: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.566623: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.573735: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.573791: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.573810: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.598094: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.598648: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.598687: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.607066: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.607103: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.607124: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.619368: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.620148: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.620187: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.627066: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.627103: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.627123: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.638973: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.639439: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.639478: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.647064: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.647103: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.647123: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.659848: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.660669: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.660730: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.670394: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.670440: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.670455: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.682687: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.683126: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.683164: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.690410: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.690460: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.690490: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.702633: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.703147: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.703186: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.710399: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.710435: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.710455: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.722856: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.723335: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.723374: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-source-ALC-1288 [009] .... 1231.730398: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 1231.730435: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.730456: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 1231.742799: snd_hdac_stream_stop: stream_tag: 1
alsa-source-ALC-1288 [009] .... 1231.743335: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 1231.743373: hda_get_response: [0000:09:00.3:0] val=0x00004011
alsa-source-ALC-1288 [009] .... 1231.750396: hda_send_cmd: [0000:09:00.3:0] val=0x00820011
alsa-source-ALC-1288 [009] .... 1231.750442: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 1231.750456: snd_hdac_stream_start: stream_tag: 1
alsa-sink-ALC89-1287 [009] .... 1231.763985: hda_send_cmd: [0000:09:00.3:0] val=0x010a0000
alsa-sink-ALC89-1287 [009] .... 1231.764042: hda_get_response: [0000:09:00.3:0] val=0x00000011
alsa-sink-ALC89-1287 [009] d..3 1231.764214: snd_hdac_stream_start: stream_tag: 5
alsa-sink-ALC89-1287 [003] d..3 1236.766032: snd_hdac_stream_stop: stream_tag: 5
alsa-source-ALC-1288 [009] d..3 1245.165326: snd_hdac_stream_stop: stream_tag: 1
[-- Attachment #4: arecordlog --]
[-- Type: application/octet-stream, Size: 987 bytes --]
# tracer: nop
#
# entries-in-buffer/entries-written: 6/6 #P:12
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
alsa-source-ALC-1288 [009] .... 2891.220869: hda_send_cmd: [0000:09:00.3:0] val=0x008a0000
alsa-source-ALC-1288 [009] .... 2891.220931: hda_get_response: [0000:09:00.3:0] val=0x00000031
alsa-source-ALC-1288 [009] .... 2891.230874: hda_send_cmd: [0000:09:00.3:0] val=0x00824011
alsa-source-ALC-1288 [009] .... 2891.230932: hda_get_response: [0000:09:00.3:0] val=0x00000000
alsa-source-ALC-1288 [009] d..3 2891.230954: snd_hdac_stream_start: stream_tag: 1
alsa-source-ALC-1288 [009] d..3 2906.506063: snd_hdac_stream_stop: stream_tag: 1
[-- Attachment #5: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ALC892 acquisition stutter
2019-04-28 9:34 ALC892 acquisition stutter rodomar705
@ 2019-04-29 15:06 ` Takashi Iwai
[not found] ` <6RvNKXcJJ9Ik3fFWf8SpH-tbFPnwT3ftuns9vv12T-wb9dryfuF8UWhjWW8-k3Z5CQEPYBBdIcaV7nPE-IX-xIqepSk8c8-kbvMeqoPdWtA=@protonmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Iwai @ 2019-04-29 15:06 UTC (permalink / raw)
To: rodomar705; +Cc: alsa-devel, kailang
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ALC892 acquisition stutter
[not found] ` <6RvNKXcJJ9Ik3fFWf8SpH-tbFPnwT3ftuns9vv12T-wb9dryfuF8UWhjWW8-k3Z5CQEPYBBdIcaV7nPE-IX-xIqepSk8c8-kbvMeqoPdWtA=@protonmail.com>
@ 2019-04-29 18:04 ` Takashi Iwai
[not found] ` <NglFwtTKvjxRbwGOg-rQE7ThssNuzPh5pLEXQv_kcLJ1PIT4-g4ErqOP0fOYBmfcJE5M-thgOfQF6L9XrdOLjROwo_J9YyU_4Wzc2gcA42Y=@protonmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Iwai @ 2019-04-29 18:04 UTC (permalink / raw)
To: rodomar705; +Cc: alsa-devel, kailang
On Mon, 29 Apr 2019 18:25:18 +0200,
rodomar705@protonmail.com wrote:
>
> Sample formats or sample rates wasn't yielding anything useful,
> unfortunately; nor the -D on the hardware. However, after setting
> --buffer-size 8192 and --period-size to 32768 the clicking are
> finally completely gone in arecord. The question remains on how to
> set this two parameters permanently to force ALSA to use them, if
> it's possible at all. (and I hope that they will not influence too
> much the delay of the acquisition).
This is a too big period size for normal use case.
> On pulseaudio, no luck in any way. tsched=0 make the acquisition 10
> times worse, regardless of the latency_msec passed to the loopback
> module that was the only "half fix", since to have clean audio I
> need a latency of 1,25s, that for doing real time communication is
> not really the ideal solution.
If the smaller period size in arecord causes a problem, it's rather
other way round; tsched=0 is for small periods but works with the
inaccurate position reporting.
OTOH, tsched=1 is basically with a huge single period in the buffer.
So, if it were only about the period size, PA tsched=1 should have
worked better. It means that something else plays another role.
> snoop=0 changed nothing,
> unfortunately, nor passing model=HDMI, generic to the codec (the
> first codec on my system is an AMD GPU card, the second is the
> integrated codec).
For these kernel module parameters, double-check that they are
properly applied. The snoop=0 should be seen in the dmesg output
where the driver will tell the snoop mode change. And the generic
model would lead to a different set of mixer elements, so you can
compare the difference in "amixer contents" output.
The fact that the period size matters implies that it *might* be a
HD-audio controller problem, not the codec. Could you give
alsa-info.sh output? Run with --no-upload option, and attach the
output.
If it's about the controller side, position_fix option might have some
influence, too. Also, with any options, try to disable the runtime
PM. At easiest, do
echo 0 > /sys/module/snd_hda_intel/parameters/power_save"
should disable the runtime PM temporarily.
Takashi
> Thanks a lot for the detailed email,
>
> I hope that someone will figure out what's causing this,
>
> Marco.
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> Il lunedì 29 aprile 2019 17:06, Takashi Iwai <tiwai@suse.de> ha scritto:
>
> > 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 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 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
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ALC892 acquisition stutter
[not found] ` <9iuKJ2ymWASO2uilTQ_UIB6Mlqwa_7SybJffDcH6Ag2zAva1J_z_-ACYUNi6nGaOQAqscry1Wj59dkLoAFgJaZGJNEdSNfiE8SR1sbwRhnI=@protonmail.com>
@ 2019-04-29 19:28 ` Takashi Iwai
[not found] ` <fMOfR-AM5BZjmykavpgjiLe3n2LgH0DSzc_k0h8Y8HlIRtBIvQ3Bd-lR-yaDR3awj3RlTfVf64otDHNKM5RMwsWVZqpX9mTl3DnbyBQlDeU=@protonmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Iwai @ 2019-04-29 19:28 UTC (permalink / raw)
To: rodomar705; +Cc: alsa-devel, kailang
On Mon, 29 Apr 2019 20:21:22 +0200,
rodomar705@protonmail.com wrote:
>
> Whoops, sorry. Here it is.
OK, it's an AMD chip and not listed explicitly in the driver config.
Does the patch below have any influence?
Takashi
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = {
/* AMD Hudson */
{ PCI_DEVICE(0x1022, 0x780d),
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
+ /* AMD family 17h */
+ { PCI_DEVICE(0x1022, 0x1457),
+ .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
/* AMD Stoney */
{ PCI_DEVICE(0x1022, 0x157a),
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ALC892 acquisition stutter
[not found] ` <fMOfR-AM5BZjmykavpgjiLe3n2LgH0DSzc_k0h8Y8HlIRtBIvQ3Bd-lR-yaDR3awj3RlTfVf64otDHNKM5RMwsWVZqpX9mTl3DnbyBQlDeU=@protonmail.com>
@ 2019-04-30 6:56 ` Takashi Iwai
0 siblings, 0 replies; 5+ messages in thread
From: Takashi Iwai @ 2019-04-30 6:56 UTC (permalink / raw)
To: rodomar705; +Cc: alsa-devel, kailang
On Tue, 30 Apr 2019 08:27:54 +0200,
rodomar705@protonmail.com wrote:
>
> Nope, neither adding AZX_DCAPS_PM_RUNTIME as seen on other AMD codecs below seems to affect it, unfortunately.
Please don't drop Cc to ML and others.
And, did you try other position_fix option value, too?
Otherwise I have out of idea. It must be platform-specific issue only
the hardware vendors know.
Takashi
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> Il lunedì 29 aprile 2019 21:28, Takashi Iwai <tiwai@suse.de> ha scritto:
>
> > On Mon, 29 Apr 2019 20:21:22 +0200,
> > rodomar705@protonmail.com wrote:
> >
> > > Whoops, sorry. Here it is.
> >
> > OK, it's an AMD chip and not listed explicitly in the driver config.
> > Does the patch below have any influence?
> >
> > Takashi
> >
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = {
> > /* AMD Hudson */
> > { PCI_DEVICE(0x1022, 0x780d),
> > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
> >
> > - /* AMD family 17h */
> > - { PCI_DEVICE(0x1022, 0x1457),
> > - .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
> >
> >
> > /* AMD Stoney */
> > { PCI_DEVICE(0x1022, 0x157a),
> > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
> >
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-04-30 6:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-28 9:34 ALC892 acquisition stutter rodomar705
2019-04-29 15:06 ` Takashi Iwai
[not found] ` <6RvNKXcJJ9Ik3fFWf8SpH-tbFPnwT3ftuns9vv12T-wb9dryfuF8UWhjWW8-k3Z5CQEPYBBdIcaV7nPE-IX-xIqepSk8c8-kbvMeqoPdWtA=@protonmail.com>
2019-04-29 18:04 ` Takashi Iwai
[not found] ` <NglFwtTKvjxRbwGOg-rQE7ThssNuzPh5pLEXQv_kcLJ1PIT4-g4ErqOP0fOYBmfcJE5M-thgOfQF6L9XrdOLjROwo_J9YyU_4Wzc2gcA42Y=@protonmail.com>
[not found] ` <9iuKJ2ymWASO2uilTQ_UIB6Mlqwa_7SybJffDcH6Ag2zAva1J_z_-ACYUNi6nGaOQAqscry1Wj59dkLoAFgJaZGJNEdSNfiE8SR1sbwRhnI=@protonmail.com>
2019-04-29 19:28 ` Takashi Iwai
[not found] ` <fMOfR-AM5BZjmykavpgjiLe3n2LgH0DSzc_k0h8Y8HlIRtBIvQ3Bd-lR-yaDR3awj3RlTfVf64otDHNKM5RMwsWVZqpX9mTl3DnbyBQlDeU=@protonmail.com>
2019-04-30 6:56 ` Takashi Iwai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.