(In reply to Steve Alexander from comment #910)
> 15 months after post #904 reoprted a work-around, and the obvious fix for
> the 17aa:380f and 17aa,3863 do not yet appear in the 6.13 kernel. Can we
> change the bug status to "ignored' or should I open a new bug report ?
Please open another report
There is a known problem for some those 4-speaker configurations with
only two DACs. In the realtek driver code, it expected to assign all 4
speakers to a single stereo DAC while a headphone is bound to another
stereo DAC. However, the actual behavior is to bind the main speaker to
one DAC and bo
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 Ubuntu
Touch seeded packages, which is
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 Ubuntu
Touch seeded packages, wh
... 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
S
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 ta
Created attachment 295735
The partial revert patch
--
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 chipse
OK, I'm going to submit this partial revert.
--
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
St
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1
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 LPIB
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 thi
Created attachment 284117
Test fis patch no.5
--
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
S
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bug
Created attachment 284111
Test fix patch no.3
--
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
S
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 becaus
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone distorted so
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/18015
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 ch
(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 -- ho
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 capt
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,
I'm
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:
--- a/s
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
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
Created attachment 284097
Test fix patch no.1
--
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
S
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 azx_get_delay_from_fi
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 Ubuntu
Touch seeded packages, which is subscribed to puls
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
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone d
(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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.
(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 rec
(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 of
(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 inp
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 wit
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
(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 cause
Created attachment 284221
Test fix patch no.7
--
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
S
OK. And changing the period_bytes_max doesn't have any influence,
either?
--
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 A
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)
trigge
Created attachment 284213
Patch to remove stream sync calls
--
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 A
(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 wh
Created attachment 284155
Test fix patch no.6
--
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
S
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. C
(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
> >
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.
--
You
Then can anyone test the hack in comment 145 together with patch#5?
--
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/1
Created attachment 284099
Test fix patch no.2
--
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
S
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 Ubuntu
Touch seeded pac
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
Created attachment 284091
A patch to show the fifo size
--
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 c
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, it'
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Micropho
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
l
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 t
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
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 positio
Created attachment 283961
A test patch for PCI 1022:1457
--
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
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 Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1801540
Title:
Microphone
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:
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 be
60 matches
Mail list logo
