Блог

При попытке настроить android-x86_64 внутри vmware-workstation16 аудиоустройство ALSA в качестве пользователя по умолчанию/непривилегированного, похоже, недоступно. Попытка вручную вызвать alsa_amixer set PCM 100% / alsa_aplay /mnt/sdcard/Download/test.wav как некорневой дает отказ в разрешении, все это прекрасно работает как root.

Поскольку Android основан на Linux, я пытался каким-то образом вручную предоставить пользователю доступ по умолчанию к определенному устройству ALSA. Я осмотрел вручную настройку /etc/group (которая, похоже, не является допустимым файлом конфигурации для Android), предоставляя доступ для чтения/записи к аудиоустройствам внутри /dev/, но я не смог определить, какое это будет устройство. Попытался вручную alsa_ctl init 0 (но устройство уже правильно инициализировано на стороне root) без разницы.

Вывод команд от имени пользователя root:

 > 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
 

Вывод команд от имени непривилегированного пользователя:

 > 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
 

Поскольку Android, похоже, не использует одинаковые групповые политики (/etc/group audio:x: ) Я не совсем уверен, как обойти изменение доступа к аудиогруппе, если таковая существует, и в этом ли проблема здесь/что еще я могу сделать.

Версия образа виртуальной машины: android-x86_64-8.1-r6

Кроме того , это, похоже, не связано с неправильной настройкой аудиоустройства хоста — при запуске alsa_aplay в качестве корневого аудио правильно маршрутизируется как аудиоклиент pulse на стороне хоста (и это слышно).

В конце концов, это было вызвано неправильной конфигурацией VMware.
Чтобы исправить это в каталоге образов виртуальной машины, для ${VMName}.vmx строки добавления (по умолчанию не должно присутствовать):

 sound.virtualDev = "hdaudio"
 

Я смутно помню, как использовал это решение с некоторыми другими настройками linux<->linux раньше.
Поскольку этот параметр недоступен через виртуальную машину графического интерфейса рабочей станции>Настройки>>Оборудование>>>Настройки звуковой карты и не был упомянут ни в официальной, ни в неофициальной документации по установке vmware на Android-x86.

Как ни странно, без включения HDAudio вы все равно можете получать вывод звука, хотя и только с помощью aplay/amixer непосредственно из tty.
Вы также можете включить такую функциональность для пользователей , не являющихся пользователями root chmod 666 /dev/snd/* , хотя приложения Android, блокируя саму шину ALSA (явно пытающуюся передавать аудиобуфер), не будут правильно перенаправлены на хост-микшер (в то время как непривилегированный tty будет).

Оставляя это на случай, если кто-то наткнется на этот вопрос или/и может продолжить, какова фактическая причина такого поведения.