summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/alsa/Makefile
AgeCommit message (Collapse)Author
2024-12-20selftests/alsa: Fix circular dependency involving global-timerLi Zhijian
The pattern rule `$(OUTPUT)/%: %.c` inadvertently included a circular dependency on the global-timer target due to its inclusion in $(TEST_GEN_PROGS_EXTENDED). This resulted in a circular dependency warning during the build process. To resolve this, the dependency on $(TEST_GEN_PROGS_EXTENDED) has been replaced with an explicit dependency on $(OUTPUT)/libatest.so. This change ensures that libatest.so is built before any other targets that require it, without creating a circular dependency. This fix addresses the following warning: make[4]: Entering directory 'tools/testing/selftests/alsa' make[4]: Circular default_modconfig/kselftest/alsa/global-timer <- default_modconfig/kselftest/alsa/global-timer dependency dropped. make[4]: Nothing to be done for 'all'. make[4]: Leaving directory 'tools/testing/selftests/alsa' Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Link: https://patch.msgid.link/20241218025931.914164-1-lizhijian@fujitsu.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-09-30selftest: alsa: check if user has alsa installedAbdul Rahim
Currently, if alsa development package is not installed on the user's system then the make command would print a `pagefull` of errors. In particular one error message is repeated 3 times. This error is returned by `pkg-config` and since it is not being handeled appropriately, repeated calls to `pkg-config` prints the same message again. This patch adds check for alsa package installation. If alsa is not installed, a short and consize error is returned. Also, it does not affect the compilation of other tests. Signed-off-by: Abdul Rahim <abdul.rahim@myyahoo.com> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://patch.msgid.link/20240922225824.18918-1-abdul.rahim@myyahoo.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-18selftests: ALSA: Cover userspace-driven timers with testIvan Orlov
Add a test for the new functionality of userspace-driven timers and the tool which allows us to count timer ticks in a certain time period. The test: 1. Creates a userspace-driven timer with ioctl to /dev/snd/timer 2. Starts the `global-timer` application to count the ticks of the timer from step 1. 3. Asynchronously triggers the timer multiple times with some interval 4. Compares the amount of caught ticks with the amount of trigger calls. Since we can't include <alsa/asoundlib.h> and <sound/asound.h> in one file due to overlapping declarations, I have to split the test into two applications: one of them counts the amount of timer ticks in the defined time period, and another one is the actual test which creates the timer, triggers it periodically and starts the first app to count the amount of ticks in a separate thread. Besides from testing the functionality itself, the test represents a sample application showing userspace-driven ALSA timers API. Also, the timer test includes a test case which tries to create a timer with invalid resolution (=0), and NULL as a timer info structure. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240813120701.171743-5-ivan.orlov0322@gmail.com
2024-05-29kselftest/alsa: Ensure _GNU_SOURCE is definedMark Brown
The pcmtest driver tests use the kselftest harness which requires that _GNU_SOURCE is defined but nothing causes it to be defined. Since the KHDR_INCLUDES Makefile variable has had the required define added let's use that, this should provide some futureproofing. Fixes: daef47b89efd ("selftests: Compile kselftest headers with -D_GNU_SOURCE") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-06-07selftests: ALSA: Add test for the 'pcmtest' driverIvan Orlov
This test covers the new Virtual PCM Test Driver, including the capturing, playback and ioctl redefinition functionalities for both interleaved and non-interleaved access modes. This test is also helpful as an usage example of the 'pcmtest' driver. We have a lot of different virtual media drivers, which can be used for testing of the userspace applications and media subsystem middle layer. However, all of them are aimed at testing the video functionality and simulating the video devices. For audio devices we have only snd-dummy module, which is good in simulating the correct behavior of an ALSA device. I decided to write a tool, which would help to test the userspace ALSA programs (and the PCM middle layer as well) under unusual circumstances to figure out how they would behave. So I came up with this Virtual PCM Test Driver. This new Virtual PCM Test Driver has several features which can be useful during the userspace ALSA applications testing/fuzzing, or testing/fuzzing of the PCM middle layer. Not all of them can be implemented using the existing virtual drivers (like dummy or loopback). Here is what can this driver do: - Simulate both capture and playback processes - Generate random or pattern-based capture data - Check the playback stream for containing the looped pattern - Inject delays into the playback and capturing processes - Inject errors during the PCM callbacks Also, this driver can check the playback stream for containing the predefined pattern, which is used in the corresponding selftest to check the PCM middle layer data transferring functionality. Additionally, this driver redefines the default RESET ioctl, and the selftest covers this PCM API functionality as well. The driver supports both interleaved and non-interleaved access modes, and have separate pattern buffers for each channel. The driver supports up to 4 channels and up to 8 substreams. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230606193254.20791-3-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-02-04kselftest/alsa: Run PCM tests for multiple cards in parallelMark Brown
With each test taking 4 seconds the runtime of pcm-test can add up. Since generally each card in the system is physically independent and will be unaffected by what's going on with other cards we can mitigate this by testing each card in parallel. Make a list of cards as we enumerate the system and then start a thread for each, then join the threads to ensure they have all finished. The threads each run the same tests we currently run for each PCM on the card before exiting. The list of PCMs is kept global since it helps with global operations like working out our planned number of tests and identifying missing PCMs and it seemed neater to check for PCMs on the right card in the card thread than make every PCM loop iterate over cards as well. We don't run per-PCM tests in parallel since in embedded systems it can be the case that resources are shared between the PCMs and operations on one PCM on a card may constrain what can be done on another PCM on the same card leading to potentially unstable results. We use a mutex to ensure that the reporting of results is serialised and we don't have issues with anything like the current test number, we could do this in the kselftest framework but it seems like this might cause problems for other tests that are doing lower level testing and building in constrained environments such as nolibc so this seems more sensible. Note that the ordering of the tests can't be guaranteed as things stand, this does not seem like a major problem since the numbering of tests often changes as test programs are changed so results parsers are expected to rely on the test name rather than the test numbers. We also now prefix the machine generated test name when printing the description of the test since this is logged before streaming starts. On my two card desktop system this reduces the overall runtime by a third. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-01-02kselftest/alsa: pcm - move more configuration to configuration filesJaroslav Kysela
Obtain all test parameters from the configuration files. The defaults are defined in the pcm-test.conf file. The test count and parameters may be variable per specific hardware. Also, handle alt_formats field now (with the fixes in the format loop). It replaces the original "automatic" logic which is not so universal. The code may be further extended to skip various tests based on the configuration hints, if the exact PCM hardware parameters are not available for the given hardware. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221208-alsa-pcm-test-hacks-v4-2-5a152e65b1e1@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-11-29selftests: alsa - move shared library configuration code to conf.cJaroslav Kysela
The minimal alsa-lib configuration code is similar in both mixer and pcm tests. Move this code to the shared conf.c source file. Also, fix the build rules inspired by rseq tests. Build libatest.so which is linked to the both test utilities dynamically. Also, set the TEST_FILES variable for lib.mk. Cc: linux-kselftest@vger.kernel.org Cc: Shuah Khan <shuah@kernel.org> Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Tested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221129085306.2345763-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-11-16selftests: alsa - add PCM testJaroslav Kysela
This initial code does a simple sample transfer tests. By default, all PCM devices are detected and tested with short and long buffering parameters for 4 seconds. If the sample transfer timing is not in a +-100ms boundary, the test fails. Only the interleaved buffering scheme is supported in this version. The configuration may be modified with the configuration files. A specific hardware configuration is detected and activated using the sysfs regex matching. This allows to use the DMI string (/sys/class/dmi/id/* tree) or any other system parameters exposed in sysfs for the matching for the CI automation. The configuration file may also specify the PCM device list to detect the missing PCM devices. v1..v2: - added missing alsa-local.h header file Cc: Mark Brown <broonie@kernel.org> Cc: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> Cc: Liam Girdwood <liam.r.girdwood@intel.com> Cc: Jesse Barnes <jsbarnes@google.com> Cc: Jimmy Cheng-Yi Chiang <cychiang@google.com> Cc: Curtis Malainey <cujomalainey@google.com> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221108115914.3751090-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-05-31selftests: alsa: Handle pkg-config failure more gracefullyMark Brown
Follow the pattern used by other selftests like memfd and fall back on the standard toolchain options to build with a system installed alsa-lib if we don't get anything from pkg-config. This reduces our build dependencies a bit in the common case while still allowing use of pkg-config in case there is a need for it. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220531151337.2933810-1-broonie@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-12-12kselftest: alsa: Add simplistic test for ALSA mixer controls kselftestMark Brown
Add a basic test for the mixer control interface. For every control on every sound card in the system it checks that it can read and write the default value where the control supports that and for writeable controls attempts to write all valid values, restoring the default values after each test to minimise disruption for users. There are quite a few areas for improvement - currently no coverage of the generation of notifications, several of the control types don't have any coverage for the values and we don't have any testing of error handling when we attempt to write out of range values - but this provides some basic coverage. This is added as a kselftest since unlike other ALSA test programs it does not require either physical setup of the device or interactive monitoring by users and kselftest is one of the test suites that is frequently run by people doing general automated testing so should increase coverage. It is written in terms of alsa-lib since tinyalsa is not generally packaged for distributions which makes things harder for general users interested in kselftest as a whole but it will be a barrier to people with Android. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20211210185410.740009-2-broonie@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>