mbox series

[v2,0/6] kselftest/alsa: pcm-test improvements

Message ID 20221201170745.1111236-1-broonie@kernel.org (mailing list archive)
Headers show
Series kselftest/alsa: pcm-test improvements | expand

Message

Mark Brown Dec. 1, 2022, 5:07 p.m. UTC
This series provides a bunch of quick updates which should make the
coverage from pcm-test a bit more useful, it adds some support for
skipping tests when the hardware/driver is unable to support the
requested configuration and then expands the set of cases we cover to
include more sample rates and channel counts.  This should exercise
switching between 8kHz and 44.1kHz based rates and ensure that clocking
doesn't get confused by non-stereo channel counts, both of which are I
expect common real world errors, at least for embedded cards.

v2:
 - Rebase onto Takashi's current tree.
 - Tweak the buffer sizes for the newly added cases, don't be quite
   so ambitious in how big a buffer we request for 96kHz and don't
   go quite so small for 8kHz since some devices start hitting lower
   limits on period size and struggle to deliver accurate timing.

Mark Brown (6):
  kselftest/alsa: Refactor pcm-test to list the tests to run in a struct
  kselftest/alsa: Report failures to set the requested sample rate as
    skips
  kselftest/alsa: Report failures to set the requested channels as skips
  kselftest/alsa: Don't any configuration in the sample config
  kselftest/alsa: Provide more meaningful names for tests
  kselftest/alsa: Add more coverage of sample rates and channel counts

 .../alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf  | 35 ++++----
 tools/testing/selftests/alsa/pcm-test.c       | 88 +++++++++++++------
 2 files changed, 81 insertions(+), 42 deletions(-)


base-commit: 2133dc91d6658242009177b564ac47c49e08668a

Comments

Takashi Iwai Dec. 1, 2022, 7:06 p.m. UTC | #1
On Thu, 01 Dec 2022 18:07:39 +0100,
Mark Brown wrote:
> 
> This series provides a bunch of quick updates which should make the
> coverage from pcm-test a bit more useful, it adds some support for
> skipping tests when the hardware/driver is unable to support the
> requested configuration and then expands the set of cases we cover to
> include more sample rates and channel counts.  This should exercise
> switching between 8kHz and 44.1kHz based rates and ensure that clocking
> doesn't get confused by non-stereo channel counts, both of which are I
> expect common real world errors, at least for embedded cards.
> 
> v2:
>  - Rebase onto Takashi's current tree.
>  - Tweak the buffer sizes for the newly added cases, don't be quite
>    so ambitious in how big a buffer we request for 96kHz and don't
>    go quite so small for 8kHz since some devices start hitting lower
>    limits on period size and struggle to deliver accurate timing.

Applied now.  Thanks.


Takashi