Neal Gompa <ngompa13(a)gmail.com> writes:
Richard Brown from openSUSE also informed me that it's
possible to do some level of audio subsystem QA using OpenQA, but I'm
not sure how to do it. Perhaps that's another avenue we can pursue to
improve integration testing coverage?
While it is technically possible to do audio testing in openQA, it is
not really used a lot. The main reason is that the current
implementation is rather brittle (albeit pretty clever): it converts the
audio signal to an image (afaik it plots the intensity) and does its
usual needle comparison. Unfortunately this does not work that well in
practice and the one of the few audio tests that openSUSE has in openQA
is a constant source of trouble, while catching very few bugs .
But even if openQA had a very reliable way to test audio, I'm afraid it
wouldn't really help us out too much here. openQA is realistically only
going to be able to cover your basic use cases, but it's not going to be
able to test all the special audio setups that all the people who are
into audio have at home (as that would require their hardware &
software). So openQA would only test what the PipeWire devs are probably
testing already anyway and it would not provide a whole lot of
additional interesting test cases.
Now, this does not mean that we shouldn't test audio in Fedora's openQA
(we don't atm), as that is still a valuable regression test. But we
won't be able to cover a lot of the more interesting use cases where I
would expect  that most of current the bugs are. Those will only get
found by running this on real world hardware by folks that have their
 I've heard this only, take this with a pinch of salt.
 emphasis on _expect_, not _know_. I really have no insight in the
maturity of PiperWire.