On Sat, 13 May 2023 22:20:36 +0200, Ivan Orlov wrote:
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 ALSA Driver.
This new Virtual ALSA 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
- 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.
Pattern-based capture stream data generation works in the following way: user can set the pattern by writing to the 'fill_pattern' debugfs file. After that, the capture stream in case of reading will be filled with this pattern (for example, if the pattern is 'abc', the capture stream will contain 'abcabcabc...'). The pattern itself can be up to 4096 bytes long.
After all, I think this driver would be a good start, and I believe in the future we will see more virtual sound drivers.
Signed-off-by: Ivan Orlov ivan.orlov0322@gmail.com
The idea is interesting, and it's a definitely good thing to have.
I wonder, though, whether it could be better provided as an extention to the existing snd-dummy driver. The advantage of extending snd-dummy driver would be that it already supports different formats, etc. OTOH, if we create an individual driver, the pro side is the simpleness of the code.
I'm inclined to go with a separate driver, but I'm open about this. Maybe Jaroslav and Mark have some opinions?
About this patch set: the driver name should be a bit more specific, as this isn't a generic virtual driver that is used for general purpose but it's only for testing. And it's only for testing PCM. So, a name like snd-test-pcm would be more appropriate, IMO.
And, we want the coverage of different formats, channels, rates and accesses (interleaved vs non-interleaved). How can we extend somehow more for that?
thanks,
Takashi