(In reply to Léo El Amri from comment #99)
> ...
> And Marco did preliminary work on this. The "jcs way" looks
> promising to me, but surely it requires a lot of work.
> ...
Yea, I'm still trying to find the energy to begin to write a parser for
the codec commands, but this will surely take quite
(In reply to Benjamin Cheng from comment #101)
> (In reply to Marco from comment #100)
>
> > Yea, I'm still trying to find the energy to begin to write a parser for the
> > codec commands, but this will surely take quite a lot of time.
>
> This actually sounds like something I would be
(In reply to Anders from comment #108)
> better now?
Thanks a lot, now I just need to go back reading the specs :P
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
(In reply to Jon from comment #111)
> Seems to affect playback as well (at least for me unless tsched=0, but even
> then get weird bugs), probably should be something like this:
>
> snd_hda_intel - Sound input/output is distorted on AM4 platforms using
> Realtek codecs.
This seems more in line
Created attachment 283619
alsa-info now completely ignores my PCI audio cards
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on
Tried everything, including downgrade to a previous kernel, same
behavior. The only thing I get in dmesg now is:
[3.146686] hdaudio hdaudioC0D0: Unable to bind the codec
[3.150739] hdaudio hdaudioC1D0: Unable to bind the codec
Really useful.
--
You received this bug notification
After purging VFIO finally the PCI audio cards works again even after
reenabling it. However now from the front panel only the right channel
works from the front jack, from the back both works correctly.
I don't really understand anything now; nor what the problem is. I'll
try to replay some
Well, another update that probably will be the last one from me, since
I'm beginning to really hate ALSA.
Decided today to try to test some parameters; I had left the audio card
loaded with VFIO module since the command dump.
Today I've decided to retry to use it, so I've removed the VFIO stubs
Tried quite a lot of different combination of quirks and older or latest
bios with the provided patch, nothing helps. The noise frequency
changes, but it is still unusable.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
(In reply to David from comment #134)
> Tried the patch on kernel 4.19.60, no sound on input.
Here it is working (5.2.2), but it's worse than before. I will try to
play with parameters now.
Thanks for the base patch, Tiwai. I'll see if with some parameters above
something will change.
However,
(In reply to Takashi Iwai from comment #140)
> Please write down exactly what you've tested. Otherwise we can't reduce the
> possible causes.
Tested the posted patch from you, same issue. Tried to enable all DCAPS
flags (except SNOOP_MASK, SNOOP_ON, because I had used as a base the
patch in
Created attachment 284085
Test patch with all DCAPS enabled for 1022:1457
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on AMD
(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
(In reply to Takashi Iwai from comment #148)
> OK, thanks, then this might indicate that the culprit is about the subtle
> timing issue, not about the cache problem.
>
> Just to be sure, could you try to pass bdl_pos_adj=64,64 option to
> snd-hda-intel module?
I feel dumb, I had some options
(In reply to Takashi Iwai from comment #153)
> It's a good news. 3 is a workaround for VIA chip, but this seems applicable
> to AMD, then.
>
> The only concern is whether the AMD chip really provides the right FIFO size
> by the register read for VIA. Could you check which value is shown by the
Created attachment 284089
Kernel Bug reported when trying to access VIA register on a AMD platform
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted
Without -N. With it the acquisition is perfect again.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on AMD chipsets
Status in
Regardless, it works even without any patch with position_fix = 3 on the
latest stable kernel, 5.2.5. I had already tried that but now it
actually works.
In the hope that this will help,
Marco.
--
You received this bug notification because you are a member of Kernel
Packages, which is
(In reply to Takashi Iwai from comment #158)
> My bad, it was a wrong place to peek the value.
>
> Below is a revised one. Also it shows the similar information that should
> be available in the stream data. This may spew many messages, so it's
> enough just to get a few messages at testing
Any additional option that we can try to fix this issue, besides trying
to contact AMD again for the chipset docs?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Latest addition, tsched=0 is still required to have decent audio
acquisition, otherwise the audio is stretched in time. A lot. Otherwise,
after setting that, the audio is perfect now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
(In reply to Takashi Iwai from comment #145)
> Hm, that's werid. Basically non-blocking mode matters only at opening the
> PCM device (whether the stream is busy or not), and it shouldn't influence
> on the running stream. Maybe it's a timing issue, like other tests failed
> sometimes...
>
>
(In reply to Takashi Iwai from comment #149)
> Also, did anyone try different position_fix options, e.g. 5,5 or 4,4?
> 4,4 should be equivalent with my previous test patch, so it's not expected
> to work.
>
> But it's still interesting to know whether the recording with such an option
> proceeds
(In reply to Takashi Iwai from comment #172)
> Thanks. The problem with playback indicates that the delay correction isn't
> good for playback but only for capture.
>
> Below is yet another revised patch. It corrects the position report only
> for the capture, but takes the FIFO delay into
Created attachment 284093
FIFO sizes from a AMD chipset
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on AMD chipsets
Status
(In reply to Takashi Iwai from comment #174)
> BTW, does anyone hit the problem on an AMD board with other PCI ID than
> 1022:1457?
Another thing, 1022:1457 is not used only on X370, but also on my B450,
and probably on a lot of other board, like B350 and such. Just a remark
for the comment
Here is the pulseaudio log and the default.pa from my system, but the
config (beside realtime scheduling) are unchanged:
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Neither did nothing, however the audio playback has no problem staying
in sync if I use directly arecord, even without pausing pulseaudio.
So, it is a pulseaudio bug, if with arecord everything works correctly?
Thanks a lot again,
Marco.
--
You received this bug notification because you are a
Created attachment 284137
pulseaudio log without tsched=0 when acquiring audio
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on
(In reply to Takashi Iwai from comment #207)
> Did you try to define AMD_FIXED_FIFO_IN_FRAMES in the patch, too?
> Also, try to increase the FIFO size defined there. The current value (256
> bytes and 32 frames) is just a guess work and it might need larger size.
>
> And, the delay happens even
(In reply to Ernst Sjöstrand from comment #214)
> There's a lot to track here now, but patch #2 seems to work great here!
>
> Patch #6 didn't seem to cause any new problems for me, but the crackling is
> still there.
6 works only with the define enabled, remove the double slashes in front
of
(In reply to Takashi Iwai from comment #200)
> A possible explanation about the delay at playback while capturing is that
> the FIFO size reported for each stream is influenced by other action. The
> patch assumed that it's constant (like other platforms do), but AMD might
> vary it per state.
>
Nothing changed, here is the trace and the actions:
1) Opened VLC with a song
2) Opened discord
3) Started mic testing, output jumped back 5 seconds in the past
4) Ended mic testing, output re synced back.
5) Stopped VLC playing
--
You received this bug notification because you are a member of
Created attachment 284211
hda_controller trace from the timing issue of my ALC892
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220
(In reply to Takashi Iwai from comment #219)
> Is this with tsched=0? I wonder why PA gets the position information so
> often. Without tsched change, PA should access to the hardware much less
> frequently.
>
> In anyway, one another interesting experiment is to reduce the max period
> size,
(In reply to Takashi Iwai from comment #224)
> OK. And changing the period_bytes_max doesn't have any influence, either?
Whoops, I completely forgot about the previous hack. Unfortunately,
nothing changes; same thing, same timing.
--
You received this bug notification because you are a member
(In reply to Takashi Iwai from comment #226)
> Then I have no better idea for now than disabling the tsched on PA.
>
> The patch below is a combination of the former patch (modified no.6) and the
> flag set to enforce tsched=0. This should work without changing PA config.
>
> Let me know if
(In reply to David from comment #238)
> Tried patch #7 without BATCH flag, this is not working with discord, there
> is a delay, and the playback stream jump around when pressing button "Let's
> Check".
Yea, same here on B450/ALC892 with tsched enabled (which AFAIK the batch
flag is the same of
(In reply to Marco from comment #251)
> (In reply to al from comment #250)
> > (In reply to Takashi Iwai from comment #249)
> > > (In reply to al from comment #248)
> > > > Thanks that did it works great now!
> > >
> > > OK, I'll add the entry for 1022:1487 in the upstream, too.
> >
> > Ok
(In reply to al from comment #250)
> (In reply to Takashi Iwai from comment #249)
> > (In reply to al from comment #248)
> > > Thanks that did it works great now!
> >
> > OK, I'll add the entry for 1022:1487 in the upstream, too.
>
> Ok thanks, I tested with discord and load-module
(In reply to Takashi Iwai from comment #172)
> Thanks. The problem with playback indicates that the delay correction isn't
> good for playback but only for capture.
>
> Below is yet another revised patch. It corrects the position report only
> for the capture, but takes the FIFO delay into
(In reply to Takashi Iwai from comment #184)
> Then can anyone test the hack in comment 145 together with patch#5?
Same behavior as without, with tsched is perfect, without the stream
jump back in time here, but the audio is clean, as mentioned in comment
180.
--
You received this bug
(In reply to Takashi Iwai from comment #216)
> (In reply to Marco from comment #211)
> > Created attachment 284171 [details]
> > Codec trace for the audio output delay problem
>
> Could you get the trace log for hda_controller, not hda?
> (/sys/kernel/debug/tracing/events/hda_controller)
>
> The
The only step is to not use tsched and try to use a software that use
webrtc as a audio backend, like Discord.
As soon as you test your mic, the audio in playback get shifted back in
time, around 5 seconds.
Thanks both for your time,
Marco.
--
You received this bug notification because you
Created attachment 284139
My default.pa config file from pulseaudio
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on AMD
(In reply to Takashi Iwai from comment #189)
> (In reply to Marco from comment #180)
> > (In reply to Takashi Iwai from comment #172)
> > > Thanks. The problem with playback indicates that the delay correction
> > isn't
> > > good for playback but only for capture.
> > >
> > > Below is yet
(In reply to Takashi Iwai from comment #221)
> OK, thanks. Then it looks like that it's really the chip that stalls the
> playback. Around time 8102 until 8106, there is no playback position update
> and proceed. The same position is kept for 4 seconds by some reason.
>
> If this happens only
(In reply to Ernst Sjöstrand from comment #137)
> (In reply to Takashi Iwai from comment #132)
> > Then possibly the playback needs LPIB while the capture position buffer?
> > A patch like below...
>
> Nope, that didn't work. Playback was fine and recording was still crackling.
>
> Is everyone
(In reply to Luca from comment #254)
> That's true, Steam Voice Chat has distortions/delays for 1 minute (but
> totally different than the usual like it was on Discord)
> Also, my voice has a much lower pitch too, and only for one minute.
>
> But I noticed this is happening on Discord too right
Created attachment 284171
Codec trace for the audio output delay problem
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted sound on ALC892/1220 on AMD
I confirm that both version of the second patch work. On playback I had
only some minor issues when the stream was starting, but after enabling
the playback patch, they disappeared too.
Without tsched=0 and without the playback patch, acquisition work
perfectly fine, but not the output, is
(In reply to Takashi Iwai from comment #273)
> Hmm, would it be only about playback? That is, restricting the workaround
> only to capture stream works better?
>
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -617,7 +617,8 @@ static int azx_pcm_open(struct
Following my previous post, disabling the batch flag on both streams
(patch 3 from comment 269), Steam is perfect, Discord is lagged again
while acquiring.
With the second patch from the comment 269, same identical problem
without the patch (Discord perfect, Steam crackling for the first minute
+
(In reply to Marco from comment #276)
> Following my previous post, disabling the batch flag on both streams (patch
> 3 from comment 269), Steam is perfect, Discord is lagged again while
> acquiring.
>
> With the second patch from the comment 269, same identical problem without
> the patch
Updates on this long endeavor as of today: I choose to give another try
for switching from PulseAudio to the PipeWire sound server.
The problems are completely gone. No audio clicking anywhere on the system.
I have tried one month ago, but on reboot I was not having any audio coming out
from
After some gaming and streaming, I can confirm that I haven't heard
anymore pops or clicks, and a lot of performance issues completely
disappeared after applying this firmware, like microstutters in the
system under load and such. Kinda makes sense, since PciEx is basically
the main bus where
(In reply to Rob McCathie from comment #292)
> I should clarify: My broken use case is capturing from the global output
> monitor while also capturing the screen, and having the audio be
> synchronised like at capture time.
>
> In some of my early tests the audio was not only un-synchronised, but
(In reply to Rob McCathie from comment #296)
> Just thought i'd update on my situation, i've now tested that it is only the
> Pulse changing to batch mode that causes my issue. So i'm no longer running
> the patch i posted earlier, rather now i do this:
>
>
>
> diff -Naur
Update after the latest firmware update for the platform, called AMD
AGESA V2 PI 1.2.0.3 Patch A, released yesterday for my platform,
finally. This includes the USB patch for the drop in the USB
communication under load for too much recovery errors hitting the Pci-Ex
subsystem on the chipset,
59 matches
Mail list logo
