Add Audio_Hamoa: ALSA-based audio playback and recording tests for Ha…#477
Add Audio_Hamoa: ALSA-based audio playback and recording tests for Ha…#477Teja Swaroop (tmoida) wants to merge 1 commit into
Conversation
Teja Swaroop (tmoida)
force-pushed
the
feature/audio-hamoa
branch
from
e479130 to
21606a2
Compare
Srikanth Muppandam (smuppand)
left a comment
Srikanth Muppandam (smuppand)
left a comment
There was a problem hiding this comment.
The Hamoa mixer details are useful, but I do not think we should add a new separate Audio_Hamoa test suite. Existing AudioPlayback and AudioRecord already provide most of the orchestration this PR reimplements: clip/config discovery, result suffixes, LAVA testcase IDs, backend/bootstrap handling, and standard result reporting.
The better approach is to add a Hamoa ALSA mixer/profile layer and reuse the existing tests:
AudioPlayback --backend alsa --alsa-profile hamoa --device handset|headset
AudioRecord --backend alsa --alsa-profile hamoa --device handset|headset
This also aligns with PR #461, where check_dependencies() can recover missing commands through the active package manager. We can add mappings for aplay/arecord/amixer to alsa-utils and let the existing tests recover dependencies instead of creating a separate suite.
Recommendation:
Extract the Hamoa mixer commands into a reusable ALSA Hamoa profile helper.
Extend existing AudioPlayback and AudioRecord with a Hamoa ALSA profile and dependency recovery through PR Add provider-based package dependency recovery #461.
Teja Swaroop (tmoida)
force-pushed
the
feature/audio-hamoa
branch
from
21606a2 to
1343228
Compare
…moa platform Fixes qualcomm-linux#454 This PR introduces comprehensive audio testing for Qualcomm Hamoa platforms using ALSA-based mixer configurations. The implementation provides automated testing for both playback and recording with hardware-specific audio path configurations. Tests audio playback on two output devices: - **Handset (plughw:0,1)**: 4-way speaker system using WSA2/WSA amplifiers - Audio path: AIF1_PB → WSA2/WSA RX0/RX1 → WooferLeft/Right + TweeterLeft/Right - 44 mixer controls configured - Dual WSA codec support with compressor and boost - **Headset (plughw:0,0)**: Stereo headphones using RX codec - Audio path: AIF1_PB → RX_MACRO RX0/RX1 → RX INT0/INT1 → HPHL/HPHR - 22 mixer controls configured - Class-H High Fidelity mode for optimal audio quality Tests audio recording on two input devices: - **Handset (plughw:0,3)**: Built-in VA_DMIC (Voice Activation DMIC) - Audio path: DMIC0/DMIC1 → VA DMIC MUX0/MUX1 → VA DEC0/DEC1 → VA_AIF1_CAP - 10 mixer controls configured - **Headset (plughw:0,2)**: External microphone using TX codec - Audio path: SWR_MIC → ADC2 → TX SMIC MUX0 → TX DEC0 → TX_AIF1_CAP - 10 mixer controls configured - **Dual device support**: Test handset, headset, or both devices - **Mixer validation**: Verifies all mixer settings before audio operations - **Clip/config-based testing**: Auto-discovery of audio clips and configurations - **CI/LAVA integration**: - Unique result file suffixes prevent file collisions in parallel runs - Unique testcase IDs prevent LAVA testcase ID collisions - Enables running multiple configurations simultaneously - **Comprehensive logging**: Mixer dumps, playback/recording logs per test case - **Recording validation**: File size and format verification - **Moved Hamoa YAML files** from `Audio_Hamoa/` subdirectories to main test directories: - `AudioPlayback/AudioPlayback_Hamoa_Handset.yaml` - `AudioPlayback/AudioPlayback_Hamoa_Headset.yaml` - `AudioRecord/AudioRecord_Hamoa_Handset.yaml` - `AudioRecord/AudioRecord_Hamoa_Headset.yaml` - **Integrated Hamoa support** into main `run.sh` scripts via ALSA profile system - **Reorganized audio utilities**: Moved `audio_common.sh` to `audio/` subdirectory - **Removed `--verbose` flag** from YAML files to eliminate warnings - **Added ALSA profile support** with `--alsa-profile` and `--device` options - **Hardware-specific mixer configuration** for Hamoa handset and headset devices - **Updated path structure**: All scripts now use `audio/audio_common.sh` - **Comprehensive README updates** for both AudioPlayback and AudioRecord: - Dedicated Hamoa ALSA Profile Support section - Hamoa usage examples with sample output from actual device - Device mapping table (handset/headset → hardware paths) - Updated directory structure showing new `audio/` organization - Hamoa-specific environment variables and CLI options documented Comprehensive README files included for both test suites: - Audio clip/config configuration tables - Test execution flow diagrams - Sample output examples - Known limitations and workarounds - CI/LAVA integration guidelines Signed-off-by: Teja Swaroop Moida <tmoida@qti.qualcomm.com>
Teja Swaroop (tmoida)
force-pushed
the
feature/audio-hamoa
branch
from
1343228 to
e4fd164
Compare
|
Srikanth Muppandam (@smuppand) Thank you for the feedback. I've implemented the recommended approach: Implementation SummaryIntegrated Hamoa into existing AudioPlayback/AudioRecord tests - no separate test suite created. Architecture Changes
Please review it and let me know your feedback. |
Srikanth Muppandam (smuppand)
left a comment
Srikanth Muppandam (smuppand)
left a comment
There was a problem hiding this comment.
This should not stay as one commit in its current form. It mixes three different types of change. Suggested commit split inside the same PR
audio: move common helpers under utils/audio
audio: add Hamoa ALSA profile helpers
audio: add Hamoa playback and capture LAVA tests
|
|
||
| # ---------------- Defaults / CLI ---------------- | ||
| AUDIO_BACKEND="" | ||
| ALSA_PROFILE="${ALSA_PROFILE:-generic}" # ALSA profile (hamoa, generic) |
There was a problem hiding this comment.
ALSA_PROFILE is introduced here, but AudioRecord does not apply the same backend coercion that AudioPlayback uses for non-generic ALSA profiles. --alsa-profile hamoa can still go through backend auto-detection and select PipeWire/PulseAudio instead of direct ALSA, so the Hamoa path may not actually be tested.
Recommended fix: before backend detection, mirror AudioPlayback’s logic: if ALSA_PROFILE is non-generic and AUDIO_BACKEND is unset, set AUDIO_BACKEND=alsa.
| SRC_ID="$AUDIO_ALSA_CAPTURE_DEVICE" | ||
| # Hardware-specific ALSA profiles (e.g., Hamoa) configure mixer controls | ||
| # and provide explicit device paths for different audio paths | ||
| if [ "$ALSA_PROFILE" != "generic" ] && [ -n "$DEVICE" ]; then |
There was a problem hiding this comment.
The Hamoa profile setup is only reached later in the ALSA source-selection block, after the earlier backend readiness check has already required the generic ALSA capture probe. If valid Hamoa capture paths can be skipped before setup_alsa_profile_hamoa_capture_* configures the mixer/device.
Recommended fix: make the earlier backend check profile-aware, or move Hamoa profile setup/device validation before the generic audio_probe_alsa_capture_profile gate.
| if [ -n "$SRC_ID" ]; then | ||
| SRC_LABEL="$(pw_source_label_safe "$SRC_ID")" | ||
| pw_set_default_source "$SRC_ID" >/dev/null 2>&1 || true | ||
| wpctl set-default "$SRC_ID" >/dev/null 2>&1 || true |
There was a problem hiding this comment.
This replaces the existing pw_set_default_source helper with a direct wpctl set-default call. It bypasses the repo’s existing PipeWire helper abstraction, so future compatibility/error handling fixes in the helper will not apply here.
Recommended fix: keep using pw_set_default_source "$SRC_ID" >/dev/null 2>&1 || true unless there is a specific helper bug being fixed in the same PR.
| if [ "$retry_alsa" -eq 1 ]; then | ||
| if printf '%s\n' "$SRC_ID" | grep -q '^hw:'; then | ||
| alt_dev="plughw:${SRC_ID#hw:}" | ||
| bytes="$(file_size_bytes "$record_out" 2>/dev/null || echo 0)" |
There was a problem hiding this comment.
bytes is now assigned only inside the if [ "$rc" -ne 0 ] branch. When the first arecord succeeds with rc=0, the later pass check can still see ${bytes:-0} as 0 and falsely fail a valid recording.
Recommended fix: assign bytes="$(file_size_bytes "$record_out" 2>/dev/null || echo 0)" immediately after rc=$?, before the if [ "$rc" -ne 0 ] block.
| . "$TOOLS/audio_common.sh" | ||
| . "$TOOLS/audio/audio_common.sh" | ||
| # shellcheck disable=SC1091 | ||
| . "$TOOLS/audio/alsa_common.sh" |
There was a problem hiding this comment.
audio_common.sh already sources alsa_common.sh, but this runner also sources alsa_common.sh directly. Helper loading is duplicated and can become unsafe if alsa_common.sh later adds non-idempotent initialization.
Recommended fix: pick one convention: either let audio_common.sh source ALSA helpers, or require callers to source both explicitly, but do not do both.
|
|
||
| # Source ALSA-specific helpers (includes Hamoa profile functions) | ||
| # Use BASH_SOURCE to get the directory of this script file when sourced | ||
| if [ -n "${BASH_SOURCE:-}" ]; then |
There was a problem hiding this comment.
The code says it uses BASH_SOURCE, but it still resolves the directory using dirname "$0". When this file is sourced, $0 points to the parent shell/script, not audio_common.sh, so alsa_common.sh can be sourced from the wrong directory or fail to load.
Recommended fix: use ${BASH_SOURCE[0]} in the bash branch, and for POSIX shells prefer $TOOLS/audio or a caller-provided helper directory.
| return 1 | ||
| fi | ||
|
|
||
| if aplay -l 2>/dev/null | grep -q "card 0"; then |
There was a problem hiding this comment.
check_alsa_device() ignores the requested $device and only checks whether aplay -l contains card 0. Impact: plughw:0,1, plughw:0,2, or plughw:0,3 may be reported accessible even if that specific PCM does not exist capture devices are also validated using playback enumeration.
Recommended fix: parse the requested card/device and validate the exact PCM, using aplay -l for playback and arecord -l for capture, or validate against /proc/asound/pcm with direction.
|
|
||
| validate_audio_file "$file" || return 1 | ||
|
|
||
| size=$(stat -c%s "$file" 2>/dev/null || stat -f%z "$file" 2>/dev/null || echo 0) |
There was a problem hiding this comment.
validate_recording() repeats direct stat size logic instead of reusing the existing file_size_bytes helper used by the audio runners. Impact: file-size behavior can drift across helpers and scripts.
Recommended fix: use file_size_bytes "$file" here so size handling remains consistent across Runner/utils audio code.
|
|
||
| # Hamoa profile wrapper for handset playback | ||
| # Args: $1 - optional log directory path | ||
| setup_alsa_profile_hamoa_playback_handset() { |
There was a problem hiding this comment.
The Hamoa profile wrappers only call the mixer setup function and return its status. The runners log that profile/device validation is handled by the profile, but the profile wrapper does not validate the selected PCM device or verify mixer state.
Recommended fix: after mixer setup, call exact ALSA device validation and validate_mixer_state for the expected profile before returning success.
|
|
||
| # Get ALSA device for Hamoa handset playback | ||
| get_alsa_device_hamoa_playback_handset() { | ||
| echo "plughw:0,1" |
There was a problem hiding this comment.
The profile-specific device getters hard-code the same device mappings already defined in the ALSA_DEVICE_* constants and exposed through get_alsa_device(). The device mappings can drift in two places.
Recommended fix: delegate these getters to get_alsa_device handset_playback, headset_playback, handset_capture, and headset_capture, or remove the profile-specific getters and call the generic helper directly.
2 participants
Add Audio_Hamoa: ALSA-based audio playback and recording tests for Hamoa platform
Fixes #454
This PR introduces comprehensive audio testing for Qualcomm Hamoa platforms using
ALSA-based mixer configurations. The implementation provides automated validation
of audio playback and recording capabilities across multiple devices.
New Test Suites
AudioPlayback_Hamoa
Tests audio playback on two output devices:
AudioRecord_Hamoa
Tests audio recording on two input devices:
Key Features
Documentation
Comprehensive README files included for both test suites: