Trying to setup android-x86_64 inside vmware-workstation16, ALSA audio device as default/unprivileged user doesn't seem to be accessible. Trying to manually call alsa_amixer set PCM 100%/alsa_aplay /mnt/sdcard/Download/test.wav as non-root gives permission denied, all of this works fine as root.
Since android is based on linux I was trying around to somehow manually give default user access to specific ALSA device. I looked around manually adjusting /etc/group (which doesn't seem to be valid config file for android), giving read/write access to audio devices inside /dev/, but I couldn't identify which device that would be.
Tried to manually alsa_ctl init 0 (but device is already correctly initialized on root's side) with no difference.
Output of commands as root user:
> alsa_aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/2 [ES1371 DAC1]
Subdevices: 1/1
Subdevice #0: subdevice #0
> alsa_ctl init 0
alsa-lib external/alsa-lib//src/ucm/main.c:1406(snd_use case_mgr_open) error: failed to import hw:0 use case config
Found hardware: "ENS1371" "Cirrus Logic CS4297A rev 3" "AC97a:43525913" "0x1274" "0x1371"
Hardware is initialized using a generic method
> cat /etc/init.sh | grep alsa
f=/system/etc/alsa/$(cat /proc/asound/card$c/id).state
alsa_ctl -f $f restore $c
alsa_ctl init $c
alsa_amixer -c $c set Master on
alsa_amixer -c $c set Master 100%
alsa_amixer -c $c set Headphone on
alsa_amixer -c $c set Headphone 100%
alsa_amixer -c $c set Speaker 100%
alsa_amixer -c $c set Capture 80%
alsa_amixer -c $c set Capture cap
alsa_amixer -c $c set PCM 100% unmute
alsa_amixer -c $c set SPO unmute
alsa_amixer -c $c set IEC958 on
alsa_amixer -c $c set 'Mic Boost' 1
alsa_amixer -c $c set 'Internal Mic Boost' 1
> ls -l /proc/asound
lrwxrwxrwx 1 root root 5 AudioPCI -> card0
dr-xr-xr-x 9 root root 0 card0
-r--r--r-- 1 root root 0 cards
-r--r--r-- 1 root root 0 devices
-r--r--r-- 1 root root 0 modules
dr-xr-xr-x 4 root root 0 oss
-r--r--r-- 1 root root 0 pcm
dr-xr-xr-x 3 root root 0 seq
-r--r--r-- 1 root root 0 timers
-r--r--r-- 1 root root 0 version
Output of commands as unprivileged user:
> alsa_aplay -l
aplay: device_list:274: no soundcards found...
> alsa_ctl init 0
alsa_ctl: snd_card_iterator_sinit:257: Cannot find soundcard '0'...
> groups
uid=10067(u0_a67) gid=10067(u0_a67) groups=10067(u0_a67)inet everybody u0_a67_cache all_a67
Since android doesn't seem to use same kind of group policies (/etc/group audio:x:) I'm not really sure how to go around modifying access to audio group if such exists and whether that's the issue here/what else I can do.
Version of VM image: android-x86_64-8.1-r6
Also , this does't seem to be issue with host audio device misconfiguration - when running alsa_aplay as root audio gets correctly routed as pulse audio client on host side (and it's audible).
This was caused by VMware misconfiguration after all.
In order to fix this inside VM's image directory, for ${VMName}.vmx append line (by default shouldn't been present):
sound.virtualDev = "hdaudio"
I vaguely remember using this solution with some other linux<->linux setup before.
As this setting is unavailable through Workstation GUI's VM>Settings>Hardware>Sound Card settings and has't been mentioned in either official nor unofficial android-x86 vmware installation documentation.
Weirdly enough without enabling HDAudio, you can still get sound output, although only using aplay/amixer directly from tty.
You can also enable such functionality on non-root user by chmod 666 /dev/snd/*, though android apps, while blocking ALSA bus itself (clearly attempting to stream audio buffer), wouldn't get routed to host mixer correctly (while unprivileged tty would).
Leaving this in case, someone stumbles on this question, or/and could extend on what's the actual cause for this behaviour.