(In reply to Takashi Iwai from comment #143) > The crucial point isn't about the DCAPS changes. Rather other points, e.g. > setting the non-cache mode *in addition* to the DCAPS changes, trying with > different formats, rates, period/buffer sizes on the modified setup, etc. > And all these combos. > > Basically, adding putting DCAPS* flags don't make sense because some of them > are mutual exclusive. Rather what I asked is to test to enable each DCAPS_* > one by one. But this test doesn't look so promising, so it'd be needed only > to make sure for now. > > Also, position_fix and bdl_pos_adj are another interesting parameters. The > test patch recently provided was based on the information about the > position_fix matters... > > Above all, the primary tests must be done via aplay/arecord with -Dhw > option, not with PulseAudio. > > *** > > What we need to know at this point is whether the problem happens at > transferring the data itself, the update timing problem, or some problem in > the codec side. > > The common problems in the past are mostly the first two items: the first > one is usually influenced by the memory cache coherency, and the second one > is the LPIB reporting / position buffer instability or the FIFO size > management. Both might be mixed together, too. > > I mentioned to test with aplay/arecord because PA is very sensible > especially about the second (timing) problem. If aplay/arecord -Dhw with a > large buffer and period works, it implies that the data transfer itself is > fine, for example. > > So, we still need to gather the facts. For that, the precise information > about *what* you tested is important. "I tested all" doesn't give you any > clue, after all ;)
Found a combination of parameters that seems to fix the issue with arecord, at least for 30 seconds, regardless of the sample rate (eg. 44100, 48000 or 192000, all now are clear recordings) is: pasuspender -- arecord -D hw:1,0 -f S32_LE -r44100 -d 10 -N -c 2 /tmp/test.wav The key parameters required are S32_LE as a format and the non blocking mode -N, otherwise the issue is still present. I hope that this will help to track down the issue. If other people here want to try it out to see if this fix their audio problems, that would be useful as well. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1801540 Title: Microphone distorted sound on ALC892/1220 on AMD chipsets Status in Linux: Confirmed Status in linux package in Ubuntu: Won't Fix Status in pulseaudio package in Ubuntu: Won't Fix Bug description: Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec. Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch. alsa-info on the attachments To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1801540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
