Re: linux-6.4 alsa sound broken

[Jeff Chua]

On Wed, May 3, 2023 at 2:06 PM Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxxxxxxxxx/
>
> 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.

Attachment: bad1.m4a
Description: video/mp4