Latest git pull from Linus's tree ... playing a simple sound file will
resulted in a lot of echo.
Running on Lenovo X1 with ..
00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
Definition Audio Controller (rev 01)
I've bisected and reverted the following patch fixed the problem.
My best,
Jeff
commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
Author: Oswald Buddenhagen <[email protected]>
Date: Thu Apr 20 13:33:23 2023 +0200
ALSA: pcm: rewrite snd_pcm_playback_silence()
The auto-silencer supports two modes: "thresholded" to fill up "just
enough", and "top-up" to fill up "as much as possible". The two modes
used rather distinct code paths, which this patch unifies. The only
remaining distinction is how much we actually want to fill.
This fixes a bug in thresholded mode, where we failed to use new_hw_ptr,
resulting in under-fill.
Top-up mode is now more well-behaved and much easier to understand in
corner cases.
This also updates comments in the proximity of silencing-related data
structures.
Signed-off-by: Oswald Buddenhagen <[email protected]>
Reviewed-by: Jaroslav Kysela <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> Latest git pull from Linus's tree ... playing a simple sound file will
> resulted in a lot of echo.
>
> Running on Lenovo X1 with ..
> 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> Definition Audio Controller (rev 01)
>
> I've bisected and reverted the following patch fixed the problem.
>
> commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
Thanks for the regression report. However, where is your dmesg and/or ALSA log
when the regression occurs? What is the playback test file?
FYI, 9f656705c5faa1 ("ALSA: pcm: rewrite snd_pcm_playback_silence()") is
originated as [1/2] of patch series that pokes around the auto-silencer. The
other patch ([2/2]) got NAKed since autofilling buffer should have been done in
alsa-lib (still to be discussed) [1].
Anyway, I'm adding this to regzbot:
#regzbot ^introduced 9f656705c5faa1
#regzbot title Much echoing when playing sound files on Intel Alder Lake PCH-P Audio Controller
Thanks.
[1]: https://lore.kernel.org/all/[email protected]/
--
An old man doll... just what I always wanted! - Clara
On Mon, 01 May 2023 06:36:49 +0200,
Bagas Sanjaya wrote:
>
> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > Latest git pull from Linus's tree ... playing a simple sound file will
> > resulted in a lot of echo.
> >
> > Running on Lenovo X1 with ..
> > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > Definition Audio Controller (rev 01)
> >
> > I've bisected and reverted the following patch fixed the problem.
> >
> > commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
>
> Thanks for the regression report. However, where is your dmesg and/or ALSA log
> when the regression occurs? What is the playback test file?
Yes, in addition, which driver is used (provide the alsa-info.sh
output at best), and which sound backend is used (pipewire, PA or
dmix) with which application?
thanks,
Takashi
On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
>Latest git pull from Linus's tree ... playing a simple sound file will
>resulted in a lot of echo.
>
how _exactly_ does it sound?
have you recorded a file through loopback for us to investigate? best
would be a short sample of a clean wave (sine or sawtooth) with some
leading and trailing silence.
>Running on Lenovo X1 with ..
>00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
>Definition Audio Controller (rev 01)
>
>I've bisected and reverted the following patch fixed the problem.
>
this seems weird. so my first thought is: are you _sure_ that your
bisect isn't "contaminated" somehow? is the effect consistent across
several reboots with the same build? does re-applying my patch
immediately re-introduce the problem?
- this code is about silencing. getting dropouts or no playback at all
would be plausible, while echo (that is, repetition) seems surprising.
theoretically, the driver may be setting a bad fill_silence() callback
which copies some garbage instead of zeroing, but the HDA driver
doesn't set one at all (i.e., uses the default one).
- this code must be explicitly enabled, which for all i know is done by
almost nothing. what players did you try? did you get consistent
results? did you try taking out audio servers from the equation?
- the affected hardware belongs to the extremely widely used HDA family,
which at the layer the patch is even remotely connected with is
completely standardized. so _a lot_ of people should be affected, and
we should be getting reports like yours by the dozen. are we?
of course i can't exclude the possibility that my patch is affected by
an uninitialized variable or memory corruption (or in the worst case
causes it), which would of course have very hard to predict effects. but
that should be investigated properly instead of just reverting, lest we
might be papering over a much more serious problem.
-- ossi
>commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
>Author: Oswald Buddenhagen <[email protected]>
>Date: Thu Apr 20 13:33:23 2023 +0200
>
> ALSA: pcm: rewrite snd_pcm_playback_silence()
>
> The auto-silencer supports two modes: "thresholded" to fill up "just
> enough", and "top-up" to fill up "as much as possible". The two modes
> used rather distinct code paths, which this patch unifies. The only
> remaining distinction is how much we actually want to fill.
>
> This fixes a bug in thresholded mode, where we failed to use new_hw_ptr,
> resulting in under-fill.
>
> Top-up mode is now more well-behaved and much easier to understand in
> corner cases.
>
> This also updates comments in the proximity of silencing-related data
> structures.
>
> Signed-off-by: Oswald Buddenhagen <[email protected]>
> Reviewed-by: Jaroslav Kysela <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Takashi Iwai <[email protected]>
On Mon, May 1, 2023 at 12:36 PM Bagas Sanjaya <[email protected]> wrote:
>
> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > Latest git pull from Linus's tree ... playing a simple sound file will
> > resulted in a lot of echo.
> >
> > Running on Lenovo X1 with ..
> > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > Definition Audio Controller (rev 01)
> >
> > I've bisected and reverted the following patch fixed the problem.
> >
> > commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
>
> Thanks for the regression report. However, where is your dmesg and/or ALSA log
> when the regression occurs? What is the playback test file?
There's no error in dmesg.
Test file is /usr/share/sounds/alsa/Side_Right.wav
>
> FYI, 9f656705c5faa1 ("ALSA: pcm: rewrite snd_pcm_playback_silence()") is
> originated as [1/2] of patch series that pokes around the auto-silencer. The
> other patch ([2/2]) got NAKed since autofilling buffer should have been done in
> alsa-lib (still to be discussed) [1].
>
> Anyway, I'm adding this to regzbot:
>
> #regzbot ^introduced 9f656705c5faa1
> #regzbot title Much echoing when playing sound files on Intel Alder Lake PCH-P Audio Controller
>
> Thanks.
>
> [1]: https://lore.kernel.org/all/[email protected]/
>
> --
> An old man doll... just what I always wanted! - Clara
On Mon, May 1, 2023 at 2:35 PM Takashi Iwai <[email protected]> wrote:
>
> On Mon, 01 May 2023 06:36:49 +0200,
> Bagas Sanjaya wrote:
> >
> > On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > > Latest git pull from Linus's tree ... playing a simple sound file will
> > > resulted in a lot of echo.
> > >
> > > Running on Lenovo X1 with ..
> > > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > > Definition Audio Controller (rev 01)
> > >
> > > I've bisected and reverted the following patch fixed the problem.
> > >
> > > commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
> >
> > Thanks for the regression report. However, where is your dmesg and/or ALSA log
> > when the regression occurs? What is the playback test file?
>
> Yes, in addition, which driver is used (provide the alsa-info.sh
> output at best), and which sound backend is used (pipewire, PA or
> dmix) with which application?
/proc/asound# cat cards devices hwdep pcm timers version
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0x603e1c8000 irq 147
1: : sequencer
2: [ 0- 0]: digital audio playback
3: [ 0- 0]: digital audio capture
4: [ 0- 3]: digital audio playback
5: [ 0- 7]: digital audio playback
6: [ 0- 8]: digital audio playback
7: [ 0- 9]: digital audio playback
8: [ 0- 0]: hardware dependent
9: [ 0- 2]: hardware dependent
10: [ 0] : control
33: : timer
00-00: HDA Codec 0
00-02: HDA Codec 2
00-00: ALC287 Analog : ALC287 Analog : playback 1 : capture 1
00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
00-08: HDMI 2 : HDMI 2 : playback 1
00-09: HDMI 3 : HDMI 3 : playback 1
G0: system timer : 10000.000us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-3-0: PCM playback 0-3-0 : SLAVE
P0-7-0: PCM playback 0-7-0 : SLAVE
P0-8-0: PCM playback 0-8-0 : SLAVE
P0-9-0: PCM playback 0-9-0 : SLAVE
Advanced Linux Sound Architecture Driver Version k6.3.0.
# test playing with ...
aplay /usr/share/sounds/alsa/Side_Right.wav
Playing WAVE '/usr/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
Little Endian, Rate 48000 Hz, Mono
I'll try to capture the sound ... it's seems to just repeating every
second until the last second. So, if you just play a "beep", its ok.
>
> thanks,
>
> Takashi
On Mon, 01 May 2023 15:16:35 +0200,
Jeff Chua wrote:
>
> On Mon, May 1, 2023 at 2:35 PM Takashi Iwai <[email protected]> wrote:
> >
> > On Mon, 01 May 2023 06:36:49 +0200,
> > Bagas Sanjaya wrote:
> > >
> > > On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > > > Latest git pull from Linus's tree ... playing a simple sound file will
> > > > resulted in a lot of echo.
> > > >
> > > > Running on Lenovo X1 with ..
> > > > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > > > Definition Audio Controller (rev 01)
> > > >
> > > > I've bisected and reverted the following patch fixed the problem.
> > > >
> > > > commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
> > >
> > > Thanks for the regression report. However, where is your dmesg and/or ALSA log
> > > when the regression occurs? What is the playback test file?
> >
> > Yes, in addition, which driver is used (provide the alsa-info.sh
> > output at best), and which sound backend is used (pipewire, PA or
> > dmix) with which application?
>
> /proc/asound# cat cards devices hwdep pcm timers version
> 0 [PCH ]: HDA-Intel - HDA Intel PCH
> HDA Intel PCH at 0x603e1c8000 irq 147
> 1: : sequencer
> 2: [ 0- 0]: digital audio playback
> 3: [ 0- 0]: digital audio capture
> 4: [ 0- 3]: digital audio playback
> 5: [ 0- 7]: digital audio playback
> 6: [ 0- 8]: digital audio playback
> 7: [ 0- 9]: digital audio playback
> 8: [ 0- 0]: hardware dependent
> 9: [ 0- 2]: hardware dependent
> 10: [ 0] : control
> 33: : timer
> 00-00: HDA Codec 0
> 00-02: HDA Codec 2
> 00-00: ALC287 Analog : ALC287 Analog : playback 1 : capture 1
> 00-03: HDMI 0 : HDMI 0 : playback 1
> 00-07: HDMI 1 : HDMI 1 : playback 1
> 00-08: HDMI 2 : HDMI 2 : playback 1
> 00-09: HDMI 3 : HDMI 3 : playback 1
> G0: system timer : 10000.000us (10000000 ticks)
> G3: HR timer : 0.001us (1000000000 ticks)
> P0-0-0: PCM playback 0-0-0 : SLAVE
> P0-0-1: PCM capture 0-0-1 : SLAVE
> P0-3-0: PCM playback 0-3-0 : SLAVE
> P0-7-0: PCM playback 0-7-0 : SLAVE
> P0-8-0: PCM playback 0-8-0 : SLAVE
> P0-9-0: PCM playback 0-9-0 : SLAVE
> Advanced Linux Sound Architecture Driver Version k6.3.0.
>
>
> # test playing with ...
> aplay /usr/share/sounds/alsa/Side_Right.wav
> Playing WAVE '/usr/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
> Little Endian, Rate 48000 Hz, Mono
>
> I'll try to capture the sound ... it's seems to just repeating every
> second until the last second. So, if you just play a "beep", its ok.
There was no description about which sound backend is used. Is it
PulseAudio, pipewire or dmix/dsnoop?
Takashi
On Mon, May 1, 2023 at 10:52 PM Takashi Iwai <[email protected]> wrote:
>
> On Mon, 01 May 2023 15:16:35 +0200,
> Jeff Chua wrote:
> >
> > On Mon, May 1, 2023 at 2:35 PM Takashi Iwai <[email protected]> wrote:
> > >
> > > On Mon, 01 May 2023 06:36:49 +0200,
> > > Bagas Sanjaya wrote:
> > > >
> > > > On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > > > > Latest git pull from Linus's tree ... playing a simple sound file will
> > > > > resulted in a lot of echo.
> > > > >
> > > > > Running on Lenovo X1 with ..
> > > > > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > > > > Definition Audio Controller (rev 01)
> > > > >
> > > > > I've bisected and reverted the following patch fixed the problem.
> > > > >
> > > > > commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
> > > >
> > > > Thanks for the regression report. However, where is your dmesg and/or ALSA log
> > > > when the regression occurs? What is the playback test file?
> > >
> > > Yes, in addition, which driver is used (provide the alsa-info.sh
> > > output at best), and which sound backend is used (pipewire, PA or
> > > dmix) with which application?
> >
> > /proc/asound# cat cards devices hwdep pcm timers version
> > 0 [PCH ]: HDA-Intel - HDA Intel PCH
> > HDA Intel PCH at 0x603e1c8000 irq 147
> > 1: : sequencer
> > 2: [ 0- 0]: digital audio playback
> > 3: [ 0- 0]: digital audio capture
> > 4: [ 0- 3]: digital audio playback
> > 5: [ 0- 7]: digital audio playback
> > 6: [ 0- 8]: digital audio playback
> > 7: [ 0- 9]: digital audio playback
> > 8: [ 0- 0]: hardware dependent
> > 9: [ 0- 2]: hardware dependent
> > 10: [ 0] : control
> > 33: : timer
> > 00-00: HDA Codec 0
> > 00-02: HDA Codec 2
> > 00-00: ALC287 Analog : ALC287 Analog : playback 1 : capture 1
> > 00-03: HDMI 0 : HDMI 0 : playback 1
> > 00-07: HDMI 1 : HDMI 1 : playback 1
> > 00-08: HDMI 2 : HDMI 2 : playback 1
> > 00-09: HDMI 3 : HDMI 3 : playback 1
> > G0: system timer : 10000.000us (10000000 ticks)
> > G3: HR timer : 0.001us (1000000000 ticks)
> > P0-0-0: PCM playback 0-0-0 : SLAVE
> > P0-0-1: PCM capture 0-0-1 : SLAVE
> > P0-3-0: PCM playback 0-3-0 : SLAVE
> > P0-7-0: PCM playback 0-7-0 : SLAVE
> > P0-8-0: PCM playback 0-8-0 : SLAVE
> > P0-9-0: PCM playback 0-9-0 : SLAVE
> > Advanced Linux Sound Architecture Driver Version k6.3.0.
> >
> >
> > # test playing with ...
> > aplay /usr/share/sounds/alsa/Side_Right.wav
> > Playing WAVE '/usr/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
> > Little Endian, Rate 48000 Hz, Mono
> >
> > I'll try to capture the sound ... it's seems to just repeating every
> > second until the last second. So, if you just play a "beep", its ok.
>
> There was no description about which sound backend is used. Is it
> PulseAudio, pipewire or dmix/dsnoop?
Just pure alsautils.
arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
[recorded.wav] attached.
[Side_Right.wav] attached.
aplay: version 1.2.8 by Jaroslav Kysela <[email protected]>
arecord: version 1.2.8 by Jaroslav Kysela <[email protected]>
alsautils, alsaplugins alsalibs all using latest git pull.
On Mon, May 1, 2023 at 3:17 PM Oswald Buddenhagen
<[email protected]> wrote:
>
> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> >Latest git pull from Linus's tree ... playing a simple sound file will
> >resulted in a lot of echo.
> >
> how _exactly_ does it sound?
> have you recorded a file through loopback for us to investigate? best
> would be a short sample of a clean wave (sine or sawtooth) with some
> leading and trailing silence.
Just send .. in another email. If the atttachment got stripped off,
please let me know.
> >Running on Lenovo X1 with ..
> >00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> >Definition Audio Controller (rev 01)
> >
> >I've bisected and reverted the following patch fixed the problem.
> >
> this seems weird. so my first thought is: are you _sure_ that your
> bisect isn't "contaminated" somehow? is the effect consistent across
> several reboots with the same build? does re-applying my patch
> immediately re-introduce the problem?
>
> - this code is about silencing. getting dropouts or no playback at all
> would be plausible, while echo (that is, repetition) seems surprising.
> theoretically, the driver may be setting a bad fill_silence() callback
> which copies some garbage instead of zeroing, but the HDA driver
> doesn't set one at all (i.e., uses the default one).
> - this code must be explicitly enabled, which for all i know is done by
> almost nothing. what players did you try? did you get consistent
> results? did you try taking out audio servers from the equation?
> - the affected hardware belongs to the extremely widely used HDA family,
> which at the layer the patch is even remotely connected with is
> completely standardized. so _a lot_ of people should be affected, and
> we should be getting reports like yours by the dozen. are we?
>
> of course i can't exclude the possibility that my patch is affected by
> an uninitialized variable or memory corruption (or in the worst case
> causes it), which would of course have very hard to predict effects. but
> that should be investigated properly instead of just reverting, lest we
> might be papering over a much more serious problem.
>
> -- ossi
>
> >commit 9f656705c5faa18afb26d922cfc64f9fd103c38d
> >Author: Oswald Buddenhagen <[email protected]>
> >Date: Thu Apr 20 13:33:23 2023 +0200
> >
> > ALSA: pcm: rewrite snd_pcm_playback_silence()
> >
> > The auto-silencer supports two modes: "thresholded" to fill up "just
> > enough", and "top-up" to fill up "as much as possible". The two modes
> > used rather distinct code paths, which this patch unifies. The only
> > remaining distinction is how much we actually want to fill.
> >
> > This fixes a bug in thresholded mode, where we failed to use new_hw_ptr,
> > resulting in under-fill.
> >
> > Top-up mode is now more well-behaved and much easier to understand in
> > corner cases.
> >
> > This also updates comments in the proximity of silencing-related data
> > structures.
> >
> > Signed-off-by: Oswald Buddenhagen <[email protected]>
> > Reviewed-by: Jaroslav Kysela <[email protected]>
> > Link: https://lore.kernel.org/r/[email protected]
> > Signed-off-by: Takashi Iwai <[email protected]>
On 5/1/23 22:03, Jeff Chua wrote:
>> There was no description about which sound backend is used. Is it
>> PulseAudio, pipewire or dmix/dsnoop?
>
> Just pure alsautils.
>
> arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
>
> [recorded.wav] attached.
> [Side_Right.wav] attached.
> aplay: version 1.2.8 by Jaroslav Kysela <[email protected]>
> arecord: version 1.2.8 by Jaroslav Kysela <[email protected]>
>
> alsautils, alsaplugins alsalibs all using latest git pull.
Are you sure you build alsa tools straight from the git repo?
Can you also reproduce with latest stable version of these?
Otherwise it's anyone's guess due to moving parts...
Thanks.
--
An old man doll... just what I always wanted! - Clara
On 5/1/23 22:05, Jeff Chua wrote:
> On Mon, May 1, 2023 at 3:17 PM Oswald Buddenhagen
> <[email protected]> wrote:
>>
>> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
>>> Latest git pull from Linus's tree ... playing a simple sound file will
>>> resulted in a lot of echo.
>>>
>> how _exactly_ does it sound?
>> have you recorded a file through loopback for us to investigate? best
>> would be a short sample of a clean wave (sine or sawtooth) with some
>> leading and trailing silence.
>
> Just send .. in another email. If the atttachment got stripped off,
> please let me know.
>
>
I don't see your attachment. Can you please post the link
to your test file on file storage hosting instead?
--
An old man doll... just what I always wanted! - Clara
On 5/3/23 11:34, Bagas Sanjaya wrote:
>> Just send .. in another email. If the atttachment got stripped off,
>> please let me know.
>>
>>
>
> I don't see your attachment. Can you please post the link
> to your test file on file storage hosting instead?
>
Oops, I don't see the attachment on your reply at [1]. Sorry for the
inconvenience.
[1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
--
An old man doll... just what I always wanted! - Clara
On Wed, May 3, 2023 at 12:40 PM Bagas Sanjaya <[email protected]> wrote:
>
> On 5/1/23 22:03, Jeff Chua wrote:
> >> There was no description about which sound backend is used. Is it
> >> PulseAudio, pipewire or dmix/dsnoop?
> >
> > Just pure alsautils.
> >
> > arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> > aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
> >
> > [recorded.wav] attached.
> > [Side_Right.wav] attached.
> > aplay: version 1.2.8 by Jaroslav Kysela <[email protected]>
> > arecord: version 1.2.8 by Jaroslav Kysela <[email protected]>
> >
> > alsautils, alsaplugins alsalibs all using latest git pull.
>
> Are you sure you build alsa tools straight from the git repo?
> Can you also reproduce with latest stable version of these?
> Otherwise it's anyone's guess due to moving parts...
All cloned from ...
https://github.com/alsa-project/alsa-lib.git
https://github.com/alsa-project/alsa-utils.git
https://github.com/alsa-project/alsa-plugins.git
arecord is symbolic link to aplay.
I just recompiled all the alsa-lib, utils and plugins, and retest and
it's the same issue.
GNU C Library (GNU libc) development release version 2.37.9000.
gcc version 11.3.1 20230315 (GCC)
binutils-2.40
Linux kernel is ...
commit 348551ddaf311c76b01cdcbaf61b6fef06a49144 (HEAD -> master,
origin/master, origin/HEAD)
Merge: 7df047b3f0aa b7badd752de0
Author: Linus Torvalds <[email protected]>
Date: Tue May 2 15:40:41 2023 -0700
Thanks,
Jeff
On Wed, 03 May 2023 06:37:48 +0200,
Bagas Sanjaya wrote:
>
> On 5/3/23 11:34, Bagas Sanjaya wrote:
> >> Just send .. in another email. If the atttachment got stripped off,
> >> please let me know.
> >>
> >>
> >
> > I don't see your attachment. Can you please post the link
> > to your test file on file storage hosting instead?
> >
>
> Oops, I don't see the attachment on your reply at [1]. Sorry for the
> inconvenience.
>
> [1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
I see no attachment of the recorded sound. In the mail above, only
Side_Right.wav was attached, and this is the same file in
/usr/share/sounds/alsa/.
But, I wonder how you played a mono channel file with "hw:1,0" PCM.
Isn't this a HD-audio device?
Usually HD-audio codec can't play a mono file. For example, on my
machine with a Realtek codec fails like:
% aplay -Dhw:0,0 Side_Right.wav
Playing WAVE 'Side_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
aplay: set_params:1358: Channels count non available
So, if it works on yours, please show the output of playback with
aplay -v option. This will show more details.
Last but not least, please double-check that the problem is really
gone after reverting the commit 9f656705c5fa. The commit is about the
auto-silencing, and it should be irrelevant unless the application
gives non-zero silence_size sw_params, and aplay doesn't set up it at
all.
thanks,
Takashi
On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <[email protected]> wrote:
>
> On Wed, 03 May 2023 06:37:48 +0200,
> Bagas Sanjaya wrote:
> >
> > On 5/3/23 11:34, Bagas Sanjaya wrote:
> > >> Just send .. in another email. If the atttachment got stripped off,
> > >> please let me know.
> > >>
> > >>
> > >
> > > I don't see your attachment. Can you please post the link
> > > to your test file on file storage hosting instead?
> > >
> >
> > Oops, I don't see the attachment on your reply at [1]. Sorry for the
> > inconvenience.
> >
> > [1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
>
> I see no attachment of the recorded sound. In the mail above, only
> Side_Right.wav was attached, and this is the same file in
> /usr/share/sounds/alsa/.
>
> But, I wonder how you played a mono channel file with "hw:1,0" PCM.
> Isn't this a HD-audio device?
> Usually HD-audio codec can't play a mono file. For example, on my
> machine with a Realtek codec fails like:
>
> % aplay -Dhw:0,0 Side_Right.wav
> Playing WAVE 'Side_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> aplay: set_params:1358: Channels count non available
>
> So, if it works on yours, please show the output of playback with
> aplay -v option. This will show more details.
# aplay -v
Playing WAVE '/local/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
Little Endian, Rate 48000 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S32_LE)
Transformation table:
0 <- 0
1 <- 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16384
period_size : 1024
period_time : 21333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
Slave: Soft volume PCM
Control: PCM Playback Volume
min_dB: -51
max_dB: 0
resolution: 256
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 1024
period_time : 21333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
silence_size : 0
boundary : 4611686018427387904
Slave: Direct Stream Mixing PCM
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 1024
period_time : 21333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 1024
period_time : 21333
tstamp_mode : ENABLE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1
stop_threshold : 4611686018427387904
silence_threshold: 0
silence_size : 4611686018427387904
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
> Last but not least, please double-check that the problem is really
> gone after reverting the commit 9f656705c5fa. The commit is about the
> auto-silencing, and it should be irrelevant unless the application
> gives non-zero silence_size sw_params, and aplay doesn't set up it at
> all.
100% sure. I just compiled the latest linux git pull. Rebooted. Tested
that the problem exists, and revert just that patch
(9f656705c5faa18afb26d922cfc64f9fd103c38d), and the problem went away!
Sorry about the recorded.wav file that I attached earlier ... didn't
realized that when I recorded via the loop-back, I could heard that it
was "corrupted" on the unpatched kernel, but when I play back the same
file on the "patched" kernel, the sound played ok.
So, loop-back using the following did not capture the problem ...
# arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
# aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
Attached is the problem file captured using my iPhone. bad1.m4a.
I've uploaded to
https://github.com/jeffersonchua/linux-6.4-alsa/blob/main/bad1.m4a in
case the attachment got stripped-off.
Thanks,
Jeff.
On Wed, 03 May 2023 14:19:54 +0200,
Jeff Chua wrote:
>
> On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <[email protected]> wrote:
> >
> > On Wed, 03 May 2023 06:37:48 +0200,
> > Bagas Sanjaya wrote:
> > >
> > > On 5/3/23 11:34, Bagas Sanjaya wrote:
> > > >> Just send .. in another email. If the atttachment got stripped off,
> > > >> please let me know.
> > > >>
> > > >>
> > > >
> > > > I don't see your attachment. Can you please post the link
> > > > to your test file on file storage hosting instead?
> > > >
> > >
> > > Oops, I don't see the attachment on your reply at [1]. Sorry for the
> > > inconvenience.
> > >
> > > [1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
> >
> > I see no attachment of the recorded sound. In the mail above, only
> > Side_Right.wav was attached, and this is the same file in
> > /usr/share/sounds/alsa/.
> >
> > But, I wonder how you played a mono channel file with "hw:1,0" PCM.
> > Isn't this a HD-audio device?
> > Usually HD-audio codec can't play a mono file. For example, on my
> > machine with a Realtek codec fails like:
> >
> > % aplay -Dhw:0,0 Side_Right.wav
> > Playing WAVE 'Side_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> > aplay: set_params:1358: Channels count non available
> >
> > So, if it works on yours, please show the output of playback with
> > aplay -v option. This will show more details.
>
> # aplay -v
> Playing WAVE '/local/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
> Little Endian, Rate 48000 Hz, Mono
> Plug PCM: Route conversion PCM (sformat=S32_LE)
> Transformation table:
> 0 <- 0
> 1 <- 0
> Its setup is:
> stream : PLAYBACK
> access : RW_INTERLEAVED
> format : S16_LE
> subformat : STD
> channels : 1
> rate : 48000
> exact rate : 48000 (48000/1)
> msbits : 16
> buffer_size : 16384
> period_size : 1024
> period_time : 21333
> tstamp_mode : NONE
> tstamp_type : MONOTONIC
> period_step : 1
> avail_min : 1024
> period_event : 0
> start_threshold : 16384
> stop_threshold : 16384
> silence_threshold: 0
> silence_size : 0
> boundary : 4611686018427387904
> Slave: Soft volume PCM
> Control: PCM Playback Volume
> min_dB: -51
> max_dB: 0
> resolution: 256
> Its setup is:
> stream : PLAYBACK
> access : MMAP_INTERLEAVED
> format : S32_LE
> subformat : STD
> channels : 2
> rate : 48000
> exact rate : 48000 (48000/1)
> msbits : 32
> buffer_size : 16384
> period_size : 1024
> period_time : 21333
> tstamp_mode : NONE
> tstamp_type : MONOTONIC
> period_step : 1
> avail_min : 1024
> period_event : 0
> start_threshold : 16384
> stop_threshold : 16384
> silence_threshold: 0
> silence_size : 0
> silence_size : 0
> boundary : 4611686018427387904
> Slave: Direct Stream Mixing PCM
> Its setup is:
> stream : PLAYBACK
> access : MMAP_INTERLEAVED
> format : S32_LE
> subformat : STD
> channels : 2
> rate : 48000
> exact rate : 48000 (48000/1)
> msbits : 32
> buffer_size : 16384
> period_size : 1024
> period_time : 21333
> tstamp_mode : NONE
> tstamp_type : MONOTONIC
> period_step : 1
> avail_min : 1024
> period_event : 0
> start_threshold : 16384
> stop_threshold : 16384
> silence_threshold: 0
> silence_size : 0
> boundary : 4611686018427387904
> Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
> Its setup is:
> stream : PLAYBACK
> access : MMAP_INTERLEAVED
> format : S32_LE
> subformat : STD
> channels : 2
> rate : 48000
> exact rate : 48000 (48000/1)
> msbits : 32
> buffer_size : 16384
> period_size : 1024
> period_time : 21333
> tstamp_mode : ENABLE
> tstamp_type : MONOTONIC
> period_step : 1
> avail_min : 1024
> period_event : 0
> start_threshold : 1
> stop_threshold : 4611686018427387904
> silence_threshold: 0
> silence_size : 4611686018427387904
> boundary : 4611686018427387904
> appl_ptr : 0
> hw_ptr : 0
OK, that explains. This is a completely different from the
configuration with hw:X,Y I expected from your description.
So, this is with dmix, and it indeed relies on the auto-silencing, so
the commit must be relevant.
> > Last but not least, please double-check that the problem is really
> > gone after reverting the commit 9f656705c5fa. The commit is about the
> > auto-silencing, and it should be irrelevant unless the application
> > gives non-zero silence_size sw_params, and aplay doesn't set up it at
> > all.
>
> 100% sure. I just compiled the latest linux git pull. Rebooted. Tested
> that the problem exists, and revert just that patch
> (9f656705c5faa18afb26d922cfc64f9fd103c38d), and the problem went away!
>
> Sorry about the recorded.wav file that I attached earlier ... didn't
> realized that when I recorded via the loop-back, I could heard that it
> was "corrupted" on the unpatched kernel, but when I play back the same
> file on the "patched" kernel, the sound played ok.
>
> So, loop-back using the following did not capture the problem ...
> # arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> # aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
>
> Attached is the problem file captured using my iPhone. bad1.m4a.
>
> I've uploaded to
> https://github.com/jeffersonchua/linux-6.4-alsa/blob/main/bad1.m4a in
> case the attachment got stripped-off.
Ah, the arecord and aplay above with -Dhw:1,1 is for a different
(still working) card? Better to explain it more clearly...
Takashi
On Wed, May 3, 2023 at 9:45 PM Takashi Iwai <[email protected]> wrote:
>
> On Wed, 03 May 2023 14:19:54 +0200,
> Jeff Chua wrote:
> >
> > On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <[email protected]> wrote:
> > >
> > > On Wed, 03 May 2023 06:37:48 +0200,
> > > Bagas Sanjaya wrote:
> > > >
> > > > On 5/3/23 11:34, Bagas Sanjaya wrote:
> > > > >> Just send .. in another email. If the atttachment got stripped off,
> > > > >> please let me know.
> > > > >>
> > > > >>
> > > > >
> > > > > I don't see your attachment. Can you please post the link
> > > > > to your test file on file storage hosting instead?
> > > > >
> > > >
> > > > Oops, I don't see the attachment on your reply at [1]. Sorry for the
> > > > inconvenience.
> > > >
> > > > [1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
> > >
> > > I see no attachment of the recorded sound. In the mail above, only
> > > Side_Right.wav was attached, and this is the same file in
> > > /usr/share/sounds/alsa/.
> > >
> > > But, I wonder how you played a mono channel file with "hw:1,0" PCM.
> > > Isn't this a HD-audio device?
> > > Usually HD-audio codec can't play a mono file. For example, on my
> > > machine with a Realtek codec fails like:
> > >
> > > % aplay -Dhw:0,0 Side_Right.wav
> > > Playing WAVE 'Side_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> > > aplay: set_params:1358: Channels count non available
> > >
> > > So, if it works on yours, please show the output of playback with
> > > aplay -v option. This will show more details.
> >
> > # aplay -v
> > Playing WAVE '/local/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
> > Little Endian, Rate 48000 Hz, Mono
> > Plug PCM: Route conversion PCM (sformat=S32_LE)
> > Transformation table:
> > 0 <- 0
> > 1 <- 0
> > Its setup is:
> > stream : PLAYBACK
> > access : RW_INTERLEAVED
> > format : S16_LE
> > subformat : STD
> > channels : 1
> > rate : 48000
> > exact rate : 48000 (48000/1)
> > msbits : 16
> > buffer_size : 16384
> > period_size : 1024
> > period_time : 21333
> > tstamp_mode : NONE
> > tstamp_type : MONOTONIC
> > period_step : 1
> > avail_min : 1024
> > period_event : 0
> > start_threshold : 16384
> > stop_threshold : 16384
> > silence_threshold: 0
> > silence_size : 0
> > boundary : 4611686018427387904
> > Slave: Soft volume PCM
> > Control: PCM Playback Volume
> > min_dB: -51
> > max_dB: 0
> > resolution: 256
> > Its setup is:
> > stream : PLAYBACK
> > access : MMAP_INTERLEAVED
> > format : S32_LE
> > subformat : STD
> > channels : 2
> > rate : 48000
> > exact rate : 48000 (48000/1)
> > msbits : 32
> > buffer_size : 16384
> > period_size : 1024
> > period_time : 21333
> > tstamp_mode : NONE
> > tstamp_type : MONOTONIC
> > period_step : 1
> > avail_min : 1024
> > period_event : 0
> > start_threshold : 16384
> > stop_threshold : 16384
> > silence_threshold: 0
> > silence_size : 0
> > silence_size : 0
> > boundary : 4611686018427387904
> > Slave: Direct Stream Mixing PCM
> > Its setup is:
> > stream : PLAYBACK
> > access : MMAP_INTERLEAVED
> > format : S32_LE
> > subformat : STD
> > channels : 2
> > rate : 48000
> > exact rate : 48000 (48000/1)
> > msbits : 32
> > buffer_size : 16384
> > period_size : 1024
> > period_time : 21333
> > tstamp_mode : NONE
> > tstamp_type : MONOTONIC
> > period_step : 1
> > avail_min : 1024
> > period_event : 0
> > start_threshold : 16384
> > stop_threshold : 16384
> > silence_threshold: 0
> > silence_size : 0
> > boundary : 4611686018427387904
> > Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
> > Its setup is:
> > stream : PLAYBACK
> > access : MMAP_INTERLEAVED
> > format : S32_LE
> > subformat : STD
> > channels : 2
> > rate : 48000
> > exact rate : 48000 (48000/1)
> > msbits : 32
> > buffer_size : 16384
> > period_size : 1024
> > period_time : 21333
> > tstamp_mode : ENABLE
> > tstamp_type : MONOTONIC
> > period_step : 1
> > avail_min : 1024
> > period_event : 0
> > start_threshold : 1
> > stop_threshold : 4611686018427387904
> > silence_threshold: 0
> > silence_size : 4611686018427387904
> > boundary : 4611686018427387904
> > appl_ptr : 0
> > hw_ptr : 0
>
> OK, that explains. This is a completely different from the
> configuration with hw:X,Y I expected from your description.
> So, this is with dmix, and it indeed relies on the auto-silencing, so
> the commit must be relevant.
>
>
> > > Last but not least, please double-check that the problem is really
> > > gone after reverting the commit 9f656705c5fa. The commit is about the
> > > auto-silencing, and it should be irrelevant unless the application
> > > gives non-zero silence_size sw_params, and aplay doesn't set up it at
> > > all.
> >
> > 100% sure. I just compiled the latest linux git pull. Rebooted. Tested
> > that the problem exists, and revert just that patch
> > (9f656705c5faa18afb26d922cfc64f9fd103c38d), and the problem went away!
> >
> > Sorry about the recorded.wav file that I attached earlier ... didn't
> > realized that when I recorded via the loop-back, I could heard that it
> > was "corrupted" on the unpatched kernel, but when I play back the same
> > file on the "patched" kernel, the sound played ok.
> >
> > So, loop-back using the following did not capture the problem ...
> > # arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> > # aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
> >
> > Attached is the problem file captured using my iPhone. bad1.m4a.
> >
> > I've uploaded to
> > https://github.com/jeffersonchua/linux-6.4-alsa/blob/main/bad1.m4a in
> > case the attachment got stripped-off.
>
> Ah, the arecord and aplay above with -Dhw:1,1 is for a different
> (still working) card? Better to explain it more clearly...
I use this to record the sound, but it's the playback that's having
the issue ...
# modprobe snd-aloop
# arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
# aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
The issue is still without reversing the patch, I'm getting the bad
audio (bad1.m4a)
Just let me know what else I can provide. I'm not sure what's need,
and don't want to bombard everyone with diagnostics that are
irrelavant.
Thank you!
Jeff
On Wed, 03 May 2023 17:06:16 +0200,
Jeff Chua wrote:
>
> On Wed, May 3, 2023 at 9:45 PM Takashi Iwai <[email protected]> wrote:
> >
> > On Wed, 03 May 2023 14:19:54 +0200,
> > Jeff Chua wrote:
> > >
> > > On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <[email protected]> wrote:
> > > >
> > > > On Wed, 03 May 2023 06:37:48 +0200,
> > > > Bagas Sanjaya wrote:
> > > > >
> > > > > On 5/3/23 11:34, Bagas Sanjaya wrote:
> > > > > >> Just send .. in another email. If the atttachment got stripped off,
> > > > > >> please let me know.
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > I don't see your attachment. Can you please post the link
> > > > > > to your test file on file storage hosting instead?
> > > > > >
> > > > >
> > > > > Oops, I don't see the attachment on your reply at [1]. Sorry for the
> > > > > inconvenience.
> > > > >
> > > > > [1]: https://lore.kernel.org/lkml/CAAJw_ZveoPfnBsSkHZqmLiVWATcOosR--6Ds4cdekdi=t1yV7A@mail.gmail.com/
> > > >
> > > > I see no attachment of the recorded sound. In the mail above, only
> > > > Side_Right.wav was attached, and this is the same file in
> > > > /usr/share/sounds/alsa/.
> > > >
> > > > But, I wonder how you played a mono channel file with "hw:1,0" PCM.
> > > > Isn't this a HD-audio device?
> > > > Usually HD-audio codec can't play a mono file. For example, on my
> > > > machine with a Realtek codec fails like:
> > > >
> > > > % aplay -Dhw:0,0 Side_Right.wav
> > > > Playing WAVE 'Side_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> > > > aplay: set_params:1358: Channels count non available
> > > >
> > > > So, if it works on yours, please show the output of playback with
> > > > aplay -v option. This will show more details.
> > >
> > > # aplay -v
> > > Playing WAVE '/local/share/sounds/alsa/Side_Right.wav' : Signed 16 bit
> > > Little Endian, Rate 48000 Hz, Mono
> > > Plug PCM: Route conversion PCM (sformat=S32_LE)
> > > Transformation table:
> > > 0 <- 0
> > > 1 <- 0
> > > Its setup is:
> > > stream : PLAYBACK
> > > access : RW_INTERLEAVED
> > > format : S16_LE
> > > subformat : STD
> > > channels : 1
> > > rate : 48000
> > > exact rate : 48000 (48000/1)
> > > msbits : 16
> > > buffer_size : 16384
> > > period_size : 1024
> > > period_time : 21333
> > > tstamp_mode : NONE
> > > tstamp_type : MONOTONIC
> > > period_step : 1
> > > avail_min : 1024
> > > period_event : 0
> > > start_threshold : 16384
> > > stop_threshold : 16384
> > > silence_threshold: 0
> > > silence_size : 0
> > > boundary : 4611686018427387904
> > > Slave: Soft volume PCM
> > > Control: PCM Playback Volume
> > > min_dB: -51
> > > max_dB: 0
> > > resolution: 256
> > > Its setup is:
> > > stream : PLAYBACK
> > > access : MMAP_INTERLEAVED
> > > format : S32_LE
> > > subformat : STD
> > > channels : 2
> > > rate : 48000
> > > exact rate : 48000 (48000/1)
> > > msbits : 32
> > > buffer_size : 16384
> > > period_size : 1024
> > > period_time : 21333
> > > tstamp_mode : NONE
> > > tstamp_type : MONOTONIC
> > > period_step : 1
> > > avail_min : 1024
> > > period_event : 0
> > > start_threshold : 16384
> > > stop_threshold : 16384
> > > silence_threshold: 0
> > > silence_size : 0
> > > silence_size : 0
> > > boundary : 4611686018427387904
> > > Slave: Direct Stream Mixing PCM
> > > Its setup is:
> > > stream : PLAYBACK
> > > access : MMAP_INTERLEAVED
> > > format : S32_LE
> > > subformat : STD
> > > channels : 2
> > > rate : 48000
> > > exact rate : 48000 (48000/1)
> > > msbits : 32
> > > buffer_size : 16384
> > > period_size : 1024
> > > period_time : 21333
> > > tstamp_mode : NONE
> > > tstamp_type : MONOTONIC
> > > period_step : 1
> > > avail_min : 1024
> > > period_event : 0
> > > start_threshold : 16384
> > > stop_threshold : 16384
> > > silence_threshold: 0
> > > silence_size : 0
> > > boundary : 4611686018427387904
> > > Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
> > > Its setup is:
> > > stream : PLAYBACK
> > > access : MMAP_INTERLEAVED
> > > format : S32_LE
> > > subformat : STD
> > > channels : 2
> > > rate : 48000
> > > exact rate : 48000 (48000/1)
> > > msbits : 32
> > > buffer_size : 16384
> > > period_size : 1024
> > > period_time : 21333
> > > tstamp_mode : ENABLE
> > > tstamp_type : MONOTONIC
> > > period_step : 1
> > > avail_min : 1024
> > > period_event : 0
> > > start_threshold : 1
> > > stop_threshold : 4611686018427387904
> > > silence_threshold: 0
> > > silence_size : 4611686018427387904
> > > boundary : 4611686018427387904
> > > appl_ptr : 0
> > > hw_ptr : 0
> >
> > OK, that explains. This is a completely different from the
> > configuration with hw:X,Y I expected from your description.
> > So, this is with dmix, and it indeed relies on the auto-silencing, so
> > the commit must be relevant.
> >
> >
> > > > Last but not least, please double-check that the problem is really
> > > > gone after reverting the commit 9f656705c5fa. The commit is about the
> > > > auto-silencing, and it should be irrelevant unless the application
> > > > gives non-zero silence_size sw_params, and aplay doesn't set up it at
> > > > all.
> > >
> > > 100% sure. I just compiled the latest linux git pull. Rebooted. Tested
> > > that the problem exists, and revert just that patch
> > > (9f656705c5faa18afb26d922cfc64f9fd103c38d), and the problem went away!
> > >
> > > Sorry about the recorded.wav file that I attached earlier ... didn't
> > > realized that when I recorded via the loop-back, I could heard that it
> > > was "corrupted" on the unpatched kernel, but when I play back the same
> > > file on the "patched" kernel, the sound played ok.
> > >
> > > So, loop-back using the following did not capture the problem ...
> > > # arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> > > # aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
> > >
> > > Attached is the problem file captured using my iPhone. bad1.m4a.
> > >
> > > I've uploaded to
> > > https://github.com/jeffersonchua/linux-6.4-alsa/blob/main/bad1.m4a in
> > > case the attachment got stripped-off.
> >
> > Ah, the arecord and aplay above with -Dhw:1,1 is for a different
> > (still working) card? Better to explain it more clearly...
>
> I use this to record the sound, but it's the playback that's having
> the issue ...
>
> # modprobe snd-aloop
> # arecord -D hw:1,0,0 -f S16_LE -r 48000 recorded.wav
> # aplay -D hw:1,1,0 /local/share/sounds/alsa/Side_Right.wav
>
> The issue is still without reversing the patch, I'm getting the bad
> audio (bad1.m4a)
>
> Just let me know what else I can provide. I'm not sure what's need,
> and don't want to bombard everyone with diagnostics that are
> irrelavant.
Thanks, now the situation got clearer.
Will investigate.
Takashi
On Mon, 01 May 2023 09:17:20 +0200,
Oswald Buddenhagen wrote:
>
> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
> > Latest git pull from Linus's tree ... playing a simple sound file will
> > resulted in a lot of echo.
> >
> how _exactly_ does it sound?
> have you recorded a file through loopback for us to investigate? best
> would be a short sample of a clean wave (sine or sawtooth) with some
> leading and trailing silence.
>
> > Running on Lenovo X1 with ..
> > 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
> > Definition Audio Controller (rev 01)
> >
> > I've bisected and reverted the following patch fixed the problem.
> >
> this seems weird. so my first thought is: are you _sure_ that your
> bisect isn't "contaminated" somehow? is the effect consistent across
> several reboots with the same build? does re-applying my patch
> immediately re-introduce the problem?
>
> - this code is about silencing. getting dropouts or no playback at all
> would be plausible, while echo (that is, repetition) seems surprising.
> theoretically, the driver may be setting a bad fill_silence()
> callback which copies some garbage instead of zeroing, but the HDA
> driver doesn't set one at all (i.e., uses the default one).
> - this code must be explicitly enabled, which for all i know is done
> by almost nothing. what players did you try? did you get consistent
> results? did you try taking out audio servers from the equation?
> - the affected hardware belongs to the extremely widely used HDA
> family, which at the layer the patch is even remotely connected with
> is completely standardized. so _a lot_ of people should be affected,
> and we should be getting reports like yours by the dozen. are we?
>
> of course i can't exclude the possibility that my patch is affected by
> an uninitialized variable or memory corruption (or in the worst case
> causes it), which would of course have very hard to predict
> effects. but that should be investigated properly instead of just
> reverting, lest we might be papering over a much more serious problem.
Oswald, this looks like a real regression by the patch.
Specially, this happens with dmix, and the issue doesn't seem specific
to the driver. It happens also with USB-audio, not only with
HD-audio. Just aplay /usr/share/sounds/alsa/Side_Left.wav or whatever
there with the dmix config showed the problem.
The dmix uses the silence_size=boundary as a fill-all operation, and
it's a free-wheel mode, so supposedly something was overlooked in your
code refactoring.
Could you check it and address quickly? I'd like to fix it before
6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
to revert the change for 6.4-rc1.
thanks,
Takashi
On 03. 05. 23 18:10, Takashi Iwai wrote:
> On Mon, 01 May 2023 09:17:20 +0200,
> Oswald Buddenhagen wrote:
>>
>> On Mon, May 01, 2023 at 11:59:12AM +0800, Jeff Chua wrote:
>>> Latest git pull from Linus's tree ... playing a simple sound file will
>>> resulted in a lot of echo.
>>>
>> how _exactly_ does it sound?
>> have you recorded a file through loopback for us to investigate? best
>> would be a short sample of a clean wave (sine or sawtooth) with some
>> leading and trailing silence.
>>
>>> Running on Lenovo X1 with ..
>>> 00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High
>>> Definition Audio Controller (rev 01)
>>>
>>> I've bisected and reverted the following patch fixed the problem.
>>>
>> this seems weird. so my first thought is: are you _sure_ that your
>> bisect isn't "contaminated" somehow? is the effect consistent across
>> several reboots with the same build? does re-applying my patch
>> immediately re-introduce the problem?
>>
>> - this code is about silencing. getting dropouts or no playback at all
>> would be plausible, while echo (that is, repetition) seems surprising.
>> theoretically, the driver may be setting a bad fill_silence()
>> callback which copies some garbage instead of zeroing, but the HDA
>> driver doesn't set one at all (i.e., uses the default one).
>> - this code must be explicitly enabled, which for all i know is done
>> by almost nothing. what players did you try? did you get consistent
>> results? did you try taking out audio servers from the equation?
>> - the affected hardware belongs to the extremely widely used HDA
>> family, which at the layer the patch is even remotely connected with
>> is completely standardized. so _a lot_ of people should be affected,
>> and we should be getting reports like yours by the dozen. are we?
>>
>> of course i can't exclude the possibility that my patch is affected by
>> an uninitialized variable or memory corruption (or in the worst case
>> causes it), which would of course have very hard to predict
>> effects. but that should be investigated properly instead of just
>> reverting, lest we might be papering over a much more serious problem.
>
> Oswald, this looks like a real regression by the patch.
> Specially, this happens with dmix, and the issue doesn't seem specific
> to the driver. It happens also with USB-audio, not only with
> HD-audio. Just aplay /usr/share/sounds/alsa/Side_Left.wav or whatever
> there with the dmix config showed the problem.
>
> The dmix uses the silence_size=boundary as a fill-all operation, and
> it's a free-wheel mode, so supposedly something was overlooked in your
> code refactoring.
>
> Could you check it and address quickly? I'd like to fix it before
> 6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
> to revert the change for 6.4-rc1.
I would revert this patch. It seems that this "do silence right after the playback is finished" mechanism is not handled in the updated code (and I overlooked that, too):
- ofs = runtime->status->hw_ptr;
- frames = new_hw_ptr - ofs;
- if ((snd_pcm_sframes_t)frames < 0)
- frames += runtime->boundary;
- runtime->silence_filled -= frames;
- if ((snd_pcm_sframes_t)runtime->silence_filled < 0) {
- runtime->silence_filled = 0;
- runtime->silence_start = new_hw_ptr;
- } else {
- runtime->silence_start = ofs;
- }
It requires to track the old and new hw_ptr, so the removal of the new_hw_ptr argument is not valid. I don't see any easy way to fix this.
I would probably fix the snd_pcm_playback_hw_avail() call with the old hw_ptr which seems like the only one issue with the original code, because it makes the threshold inaccurate (it is expected to fill more silent samples). Another issue is wrong silence_start for the incremental silence calls.
The patch to fix the original code may look like:
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index af1eb136feb0..70795a83e50a 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -45,7 +45,7 @@ static int fill_silence_frames(struct snd_pcm_substream *substream,
void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_uframes_t new_hw_ptr)
{
struct snd_pcm_runtime *runtime = substream->runtime;
- snd_pcm_uframes_t frames, ofs, transfer;
+ snd_pcm_uframes_t start, frames, ofs, transfer;
int err;
if (runtime->silence_size < runtime->boundary) {
@@ -63,12 +63,17 @@ void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_ufram
}
if (runtime->silence_filled >= runtime->buffer_size)
return;
+ /* use appl_ptr as a temporary variable */
+ appl_ptr = runtime->status->hw_ptr;
+ runtime->status->hw_ptr = new_hw_ptr;
noise_dist = snd_pcm_playback_hw_avail(runtime) + runtime->silence_filled;
+ runtime->status->hw_ptr = appl_ptr;
if (noise_dist >= (snd_pcm_sframes_t) runtime->silence_threshold)
return;
frames = runtime->silence_threshold - noise_dist;
if (frames > runtime->silence_size)
frames = runtime->silence_size;
+ start = (runtime->silence_start + runtime->silence_filled) % runtime->boundary;
} else {
if (new_hw_ptr == ULONG_MAX) { /* initialization */
snd_pcm_sframes_t avail = snd_pcm_playback_hw_avail(runtime);
@@ -92,12 +97,13 @@ void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_ufram
}
}
frames = runtime->buffer_size - runtime->silence_filled;
+ start = runtime->silence_start;
}
if (snd_BUG_ON(frames > runtime->buffer_size))
return;
if (frames == 0)
return;
- ofs = runtime->silence_start % runtime->buffer_size;
+ ofs = start % runtime->buffer_size;
while (frames > 0) {
transfer = ofs + frames > runtime->buffer_size ? runtime->buffer_size - ofs : frames;
err = fill_silence_frames(substream, ofs, transfer);
I'll post a complete patch when we agree on this solution. The runtime->status->hw_ptr may not be even preserved, because it is no used in the rest of code in snd_pcm_update_hw_ptr0(), but the code looks more sane.
Jaroslav
--
Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
On Wed, May 03, 2023 at 09:32:02PM +0200, Jaroslav Kysela wrote:
>On 03. 05. 23 18:10, Takashi Iwai wrote:
>> The dmix uses the silence_size=boundary as a fill-all operation, and
>> it's a free-wheel mode, so supposedly something was overlooked in your
>> code refactoring.
>>
>> Could you check it and address quickly? I'd like to fix it before
>> 6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
>> to revert the change for 6.4-rc1.
>
>I would revert this patch.
> It seems that this "do silence right after the playback is finished"
> mechanism is not handled in the updated code (and I overlooked that,
> too):
>
no, there is nothing wrong with the code _per se_.
what's happening is that the dmix plugin doesn't update the application
pointer, and somehow gets away with it.
that means that it would have never worked with thresholded silencing
mode, either, but, well, it uses top-up mode.
anyway, this means that we need to revert the code path for top-up mode,
which means reverting most of the patch's "meat".
i think i can do better than your proposal, but not today anymore.
fwiw, the echo results from the plugin apparently summing up the samples
in the buffer without clearing it first, that is, it relies on the
auto-silencing doing the clearing, which the patch broke under the given
circumstances. rather obvious in retrospect.
regards
On 03. 05. 23 22:00, Oswald Buddenhagen wrote:
> On Wed, May 03, 2023 at 09:32:02PM +0200, Jaroslav Kysela wrote:
>> On 03. 05. 23 18:10, Takashi Iwai wrote:
>>> The dmix uses the silence_size=boundary as a fill-all operation, and
>>> it's a free-wheel mode, so supposedly something was overlooked in your
>>> code refactoring.
>>>
>>> Could you check it and address quickly? I'd like to fix it before
>>> 6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
>>> to revert the change for 6.4-rc1.
>>
>> I would revert this patch.
>
>> It seems that this "do silence right after the playback is finished"
>> mechanism is not handled in the updated code (and I overlooked that,
>> too):
>>
> no, there is nothing wrong with the code _per se_.
>
> what's happening is that the dmix plugin doesn't update the application
> pointer, and somehow gets away with it.
Dmix uses the free mode, because multiple applications can write to the
buffer. We cannot do application pointer updates in the shared resource.
> anyway, this means that we need to revert the code path for top-up mode,
> which means reverting most of the patch's "meat".
> i think i can do better than your proposal, but not today anymore.
Ok, let's see. I tried to be minimalistic to fix bugs and then we can talk
about the improvements.
> fwiw, the echo results from the plugin apparently summing up the samples
> in the buffer without clearing it first, that is, it relies on the
> auto-silencing doing the clearing, which the patch broke under the given
> circumstances. rather obvious in retrospect.
Dmix does not know which samples were updated by other applications. The
application tracks only own samples.
Jaroslav
--
Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
On Wed, 03 May 2023 22:00:37 +0200,
Oswald Buddenhagen wrote:
>
> On Wed, May 03, 2023 at 09:32:02PM +0200, Jaroslav Kysela wrote:
> > On 03. 05. 23 18:10, Takashi Iwai wrote:
> >> The dmix uses the silence_size=boundary as a fill-all operation, and
> >> it's a free-wheel mode, so supposedly something was overlooked in your
> >> code refactoring.
> >>
> >> Could you check it and address quickly? I'd like to fix it before
> >> 6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
> >> to revert the change for 6.4-rc1.
> >
> > I would revert this patch.
>
> > It seems that this "do silence right after the playback is finished"
> > mechanism is not handled in the updated code (and I overlooked that,
> > too):
> >
> no, there is nothing wrong with the code _per se_.
>
> what's happening is that the dmix plugin doesn't update the
> application pointer, and somehow gets away with it.
>
> that means that it would have never worked with thresholded silencing
> mode, either, but, well, it uses top-up mode.
Well, the code made just a wrong interpretation for the behavior with
silence_size == boundary. This mode is actually a kind of tailored
operation for dmix.
In the description of alsa-lib snd_pcm_sw_params_set_silence_size(),
you can find it:
/**
* \brief Set silence size inside a software configuration container
* \param pcm PCM handle
* \param params Software configuration container
* \param val Silence size in frames (0 for disabled)
* \return 0 otherwise a negative error code
*
* A portion of playback buffer is overwritten with silence when playback
* underrun is nearer than silence threshold (see
* #snd_pcm_sw_params_set_silence_threshold)
*
* The special case is when silence size value is equal or greater than
* boundary. The unused portion of the ring buffer (initial written samples
* are untouched) is filled with silence at start. Later, only just processed
* sample area is filled with silence. Note: silence_threshold must be set to zero.
*/
So, the "top-up" silencing happens only at start, but not after that.
In the code path of hw_ptr update, it doesn't check the appl_ptr any
longer, but fills the processed area by the hw_ptr update with
silence. That's the intended behavior for use cases of free-wheel
mode without appl_ptr updates like dmix.
Takashi