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@xxxxxxxxx> 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
