Open ssavati opened 2 months ago
BTW do you know why we have all these SKIPs? https://sof-ci.01.org/sofpr/PR9455/build7827/devicetest/index.html?model=LNLM_RVP_HDA&testcase=check-alsabat-nocodec-32bits-599
I am not sure why we have an alsa-bat test that's specific to the nocodec mode, but it makes sense that it would only be applied to nocodec platforms and skipped for both HDaudio and SoundWire platforms.
usb_audio_found() { aplay -l | grep -q 'USB Audio' }
This is also fragile in that it will fail if there's a USB device connected by accident. I think it's better to rely on environment variables set by the CI setup to understand when we want to use the analog dongle or the USB loopback.
This is also fragile in that it will fail if there's a USB device connected by accident.
These loopback setups involve a fair amount of cables and are a bit tedious to install, it's not really something anyone has been connecting "by accident".
I think it's better to rely on environment variables set by the CI setup to understand when we want to use the analog dongle or the USB loopback.
The main issue is: we don't have a reliable way to maintain per-device settings (in fact we don't even have a reliable way to maintain consistent settings either). Unlike hardware configuration "accidents", software configuration accidents have been happening regularly.
Considering it's impossible for a device to be able to test both configurations, merely echoing the hardware configuration in a configuration file manually seems just error-prone with no value.
All this being said, usb_audio_found()
can very easily be replaced by TEST_USB_LOOPBACK=true
in my sample code. My suggestion was not just about that.
BTW do you know why we have all these SKIPs? https://sof-ci.01.org/sofpr/PR9455/build7827/devicetest/index.html?model=LNLM_RVP_HDA&testcase=check-alsabat-nocodec-32bits-599