For ASUS-specific codec issues, could you open another bug instead of
hanging this old issue? The AMD controller problem was basically fixed,
and the Realtek codec quirk is a different story.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
Again a correction: the current default setup for Raven corresponds to
position_fix=6 option. It's not a simple LPIB read but contains some
awkward correction that takes the FIFO size into account.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Created attachment 295735
The partial revert patch
--
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
OK, I'm going to submit this partial revert.
--
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 Linux:
Yes, that's merely an ugly workaround, and I'd happily get rid of it
once after confirming it's working fine without that!
--
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:
1487 is with the same setup as Raven (15e3), and the same workaround is
applied.
Please note that the workaround isn't actually delaying the sound
transfer. Instead, it reports the PCM delay value up to 32bytes for
FIFO size for the applications. If the application (the sound backend)
doesn't
... and looking back at the development history again, this seems too early to
be delighted. Actually the change to PRESET_AMD_SB was done as a fix for the
certain devices in the commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2
ALSA: hda - Apply AMD controller workaround for Raven platform
That's a good discovery. This change makes sense, as the different of
PRESET_ATI_SB from PRESET_AMD_SB is about the position reporting. ATI_SB uses
the legacy LPIB register read while AMD_SB uses the position buffer table.
This could be verified by changing position_fix module option: 1 is
Yours has a different controller chip, so the patch doesn't have any
effect as is.
Try a freshly submitted / merged patch on top of the previous fixes:
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d2c63b7dfd06788a466d5ec8a850491f084c5fc2
--
You received this bug
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 account, too.
--
You received this bug notification
OK, thanks. Could you try another one below, too?
This should be a more correct way from API POV, passing the delay value
instead of the direct correction of the position.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Created attachment 284111
Test fix patch no.3
--
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 Linux:
Created attachment 284113
Test fix patch (revised)
The previous one won't work, I'm afraid. This is the revised one
(no.4).
--
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:
Created attachment 284117
Test fis patch no.5
--
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 Linux:
BTW, does anyone hit the problem on an AMD board with other PCI ID than
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
(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.
--
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
(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 another revised patch. It corrects the position report only
> >
OK. And changing the period_bytes_max doesn't have any influence,
either?
--
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
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 snd_pcm_substream *substream)
* tsched=1 when a
OK, that's good to know.
And how is the application set up? Does it run over PulseAudio backend
or accesses directly ALSA devices?
The BATCH workaround was needed for PulseAudio. Does any other
application using PulseAudio (wrt capture) work on your device?
And it'd be strange if this setup
(In reply to daxcore from comment #229)
> completely not working here. also not patch 7. with pa sound is jumping, and
> with alsa I just get a random noise.
>
> does this work for anybody with X399 board alc1220?
That sounds like a different problem. Especially a random noise
shouldn't be
What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1],
together with dropping SNDRV_PCM_INFO_BATCH flag? Still getting the
same problem?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
(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 former tracks the PCM events including the position report
Created attachment 284155
Test fix patch no.6
--
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 Linux:
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.
The patch below (fix6) takes a hard-coded FIFO size.
Then can anyone test the hack in comment 145 together with patch#5?
--
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
For all people who still see the problem: please test 5.3-rc6 or rc7
kernel and confirm that the problem persists.
Once after confirming the same issue with 5.3-rc7, and it's about the
PCI device 1022:1457 or 1022:1487, then check the following:
1. Change the return value of
(In reply to Ernst Sjöstrand from comment #244)
> So with patch 7, but tsched=1 (ie. not the part with |= BATCH included) I
> get the following:
>
> Only test idea 1: crackling
> 1+2: no crackling but playback skips when start/stop recording
> 2: no crackling but playback skips when start/stop
(In reply to al from comment #245)
> I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220.
Judging from alsa-info.sh output, your device has a different PCI device ID,
1022:1487. Replace the entry and retest.
--
You received this bug notification because you are a member
(In reply to Ernst Sjöstrand from comment #240)
> (In reply to Takashi Iwai from comment #237)
> > What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1],
> > together with dropping SNDRV_PCM_INFO_BATCH flag? Still getting the same
> > problem?
>
> I getting the crackling mic
Basically patch 2 and 7 are essentially doing same wrt the position
report. The latter uses the fixed FIFO size instead of reading the
register and it reports the actual delay size as well. But the
difference is likely irrelevant with PA tsched problem Marco was seeing.
I guess PA would work
(In reply to Térence Clastres from comment #232)
> I notice the following in the log with patch 7:
> Also, I don't know if it's expected but enabling 'mic boost' produces a lot
> of noise.
>
> pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: We were
> woken up with POLLIN set --
Created attachment 284221
Test fix patch no.7
--
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 Linux:
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 this works better. If the things work reasonably enough,
Created attachment 284213
Patch to remove stream sync calls
--
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
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 at the full-duplex (capture and playback mixture)
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, something like below on top of the previous patch:
---
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 with the patch no.6? Then my theory wasn't
right, and
Created attachment 284157
The correct no.6 test patch
Oops, sorry the previous no.6 was wrong. The correct one here.
--
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:
It's hard to say whether it's a PA bug. I still doubt it being some
inconsistent behavior of the driver, triggered only by some specific
condition PA hits.
Could you start PA with more verbosity and check whether PA complains
anything at starting capture? It might be that the incorrect position
For those with non-working systems: first off, make sure that you're
really testing the patched kernel, e.g. put a printk() for checking.
Then test without PulseAudio at first, with aplay/arecord (with -Dhw:0
or -Dhw:1, depending on the system). As in comment 144, try with or
without -N.
--
Created attachment 284099
Test fix patch no.2
--
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 Linux:
Created attachment 284097
Test fix patch no.1
--
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 Linux:
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 patch below? If it's 32 or some reasonable number,
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 recording.
--
You received this bug notification because
OK, that looks more promising.
Now I cooked two patches. The first one is to simply apply the existing
VIA position fix to the AMD X370 platform (1022:1457). This should work
like the test you've done now without any option.
The second one is an attempt with simpler position fix, just reducing
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...
Did you already try using non-cached buffer in addition to
Created attachment 284091
A patch to show the fifo size
--
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
No need for retest, bdl_pos_adj is merely a shot-in-the-dark, and likely
breaks something else :)
--
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
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?
--
You received this bug notification because you are a member of Kernel
Packages, which
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 at all. If the stream can be recorded for the expected
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
Please write down exactly what you've tested. Otherwise we can't reduce
the possible causes.
--
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
That's bad that the chipset shows inconsistent behavior. How did you
test exactly and how it's broken without AZX_DCAPS_POSFIX_LPIB?
As mentioned in comment 125, the first thing to do is to assure your PCI device
listed in the azx_ids[] table explicitly. If not, create an entry to pass like:
Then possibly the playback needs LPIB while the capture position buffer?
A patch like below...
--
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
Created attachment 283961
A test patch for PCI 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 chipsets
Status
Well, it's still not clear who to blame. Practically seen, the problem
appears on a certain Realtek codecs just because there are such codec
chips on the market for major mobos. Except for a few vendors (like
Apple), all boards are equipped with Realtek codecs. So, I still
suspect the problem
Hm, interesting, AZX_DCAPS_POSFIX_LPIB basically sets the position
reporting based on LPIB instead of the position buffer. I thought the
position buffer isn't available or unreliable on non-Intel chips, but it
might be different on the recent AMD one.
FWIW, you can change the behavior via
Created attachment 284299
The patch that will be merged for 5.4 kernel
Should be applicable on 5.3 kernel cleanly.
--
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/1721987
Title:
No
This bug has been forgotten for a while, sorry for that.
Since the verbs are reverse-engineered and there is a significant risk
of breakage, we shouldn't apply it as default *yet*. So, instead, the
workaround is applied when user explicitly specifies the model=huawei-
mbx-stereo option to
(In reply to jcs from comment #7)
> Here is the magic sequence of CORB commands needed to enable both speakers.
> This is actually part of a much larger sequence that the Windows driver
> does, but through trial and error, this is the minimum required to make both
> speakers work.
That's great!
>From the given alsa-info.sh output, there is nothing wrong there.
So it must be some vendor-specific initialization, and only Huawei knows.
Try to contact your vendor.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
62 matches
Mail list logo
