| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87a5ylcyw4.wl-tiwai@suse.de>
Date: Wed, 03 May 2023 15:44:59 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Jeff Chua <jeff.chua.linux@...il.com>
Cc: Takashi Iwai <tiwai@...e.de>, Bagas Sanjaya <bagasdotme@...il.com>,
Oswald Buddenhagen <oswald.buddenhagen@....de>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: linux-6.4 alsa sound broken
On Wed, 03 May 2023 14:19:54 +0200,
Jeff Chua wrote:
>
> On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <tiwai@...e.de> 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
Powered by blists - more mailing lists