On Mon, 29 Apr 2019 18:25:18 +0200, rodomar705@xxxxxxxxxxxxxx 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@xxxxxxx> ha scritto: > > > On Sun, 28 Apr 2019 11:34:34 +0200, > > rodomar705@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxx > > > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
