You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AUD001.001 and AUD001.002 present inconsistent behavior. These two test are Ubuntu and Windows variants of audio detection.
AUD001.001 (Ubuntu) uses sysfs to peek a chip_name property from predefined path. This ignores if the device is actually used as output device, and presents the state more from kernel's perspective.
AUD001.002 (Windows) uses powershell to get audio devices, but this might fail, if no output device is available (HDMI display or other). This is closer to "user-space perspective".
Describe the solution you'd like
Match behavior of both these tests. In case of fail, we could notify user to make sure that proper device is connected.
Where is the value to a user, and who might that user be?
No response
Describe alternatives you've considered
Replace Get-WmiObject with Get-CimInstance, which is more modern according to MS Documentation. This however does not fix the issue.
There is also Get-PnpDevice which will detect all audio devices, no matter the device state.
Additional context
No response
The text was updated successfully, but these errors were encountered:
The problem you're addressing (if any)
AUD001.001 and AUD001.002 present inconsistent behavior. These two test are Ubuntu and Windows variants of audio detection.
AUD001.001 (Ubuntu) uses sysfs to peek a chip_name property from predefined path. This ignores if the device is actually used as output device, and presents the state more from kernel's perspective.
AUD001.002 (Windows) uses powershell to get audio devices, but this might fail, if no output device is available (HDMI display or other). This is closer to "user-space perspective".
Describe the solution you'd like
Match behavior of both these tests. In case of fail, we could notify user to make sure that proper device is connected.
Where is the value to a user, and who might that user be?
No response
Describe alternatives you've considered
Replace Get-WmiObject with Get-CimInstance, which is more modern according to MS Documentation. This however does not fix the issue.
There is also Get-PnpDevice which will detect all audio devices, no matter the device state.
Additional context
No response
The text was updated successfully, but these errors were encountered: