Message ID | 20221130000608.519574-7-broonie@kernel.org |
---|---|
State | Superseded |
Headers | show |
Series | kselftest/alsa: pcm-test improvements | expand |
On Wed, Nov 30, 2022 at 12:06:08AM +0000, Mark Brown wrote: > + { "8k.1.big", "S16_LE", 8000, 2, 2000, 16000 }, > + { "8k.2.big", "S16_LE", 8000, 2, 4000, 32000 }, > + { "44k1.2.big", "S16_LE", 44100, 2, 22050, 192000 }, > + { "48k.2.small", "S16_LE", 48000, 2, 512, 4096 }, > + { "48k.2.big", "S16_LE", 48000, 2, 24000, 192000 }, > + { "48k.6.big", "S16_LE", 48000, 6, 48000, 576000 }, > + { "96k.2.big", "S16_LE", 96000, 2, 48000, 384000 }, It looks like the period/buffer size numbers need some tuning other than for 44.1kHz and 48kHz 6 channel, if I do any more fiddling with this series I'll split the problematic ones out into a separate commit if I don't get things sorted (but we could just leave things as-is and fix incrementally too I guess).
diff --git a/tools/testing/selftests/alsa/pcm-test.c b/tools/testing/selftests/alsa/pcm-test.c index 614ccc52cece..d76a6f15ce25 100644 --- a/tools/testing/selftests/alsa/pcm-test.c +++ b/tools/testing/selftests/alsa/pcm-test.c @@ -517,8 +517,13 @@ static void test_pcm_time1(struct pcm_data *data, static const struct time_test_def time_tests[] = { /* name format rate chan period buffer */ - { "S16.48k.2.small", "S16_LE", 48000, 2, 512, 4096 }, - { "S16.48k.2.big", "S16_LE", 48000, 2, 24000, 192000 }, + { "8k.1.big", "S16_LE", 8000, 2, 2000, 16000 }, + { "8k.2.big", "S16_LE", 8000, 2, 4000, 32000 }, + { "44k1.2.big", "S16_LE", 44100, 2, 22050, 192000 }, + { "48k.2.small", "S16_LE", 48000, 2, 512, 4096 }, + { "48k.2.big", "S16_LE", 48000, 2, 24000, 192000 }, + { "48k.6.big", "S16_LE", 48000, 6, 48000, 576000 }, + { "96k.2.big", "S16_LE", 96000, 2, 48000, 384000 }, }; int main(void)
Now that we can skip unsupported configurations add some more test cases using that, cover 8kHz, 44.1kHz and 96kHz plus 8kHz mono and 48kHz 6 channel. 44.1kHz is a different clock base to the existing 48kHz tests and may therefore show problems with the clock configuration if only 8kHz based rates are really available (or help diagnose if bad clocking is due to only 44.1kHz based rates being supported). 8kHz mono and 48Hz 6 channel are real world formats and should show if clocking does not account for channel count properly. Signed-off-by: Mark Brown <broonie@kernel.org> --- tools/testing/selftests/alsa/pcm-test.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)