qemu: opening 4a role returns empty device string (bad audio dev detection)
Description
Environment
Attachments
- 03 Aug 2018, 08:26 AM
- 03 Aug 2018, 08:15 AM
Activity
Walt Miner September 6, 2018 at 9:18 PM
Close for FF RC5
Loïc Collignon [ IoT.bzh ] August 7, 2018 at 7:04 AM
I do not completly agree on that.
From the high level api point of view, an empty device string can be normal, as it is a configuration that provide the whole thing. You can decide to not attribute a device to a role if you don't want this role to be playable but still want to get policy manager involved.
Also, by default, all hal are enabled, and we know which one to use because only one hal find it's linked hardware. And you can enable/disable hal during the runtime. So I can't tell if an empty device string is normal or not. Because it can be filled later on.
And finally, you may have multiple audio cards and enable the hals for each of them, and configure that the multimedia role should play on card 1, but emergency should play on card 2. So when I populate the role list, I can't tell if it's normal that a hal provide a device for one role but not for another one.
A better solution would that the high level api ask the hal manager if there is any enabled hal, and if there is no hal at all, that's may be an issue. But again, what if this is on purpose ? So first of all we may want to answer that: is there any use case where having no enabled hal is wanted ?
George Kiagiadakis August 6, 2018 at 10:14 AM
Stephane, I would also add a 3rd bullet to your issue list:
Report failure on opening the device if the underlying hardware is not detected or not working properly. From an API point of view, returning "success" with an empty device string is just weird... or at least it should be documented that this is possible to happen
Jan-Simon Moeller August 4, 2018 at 11:11 AM
Hi !
That ID is not guaranteed to be the same on different VMs (qemu, vmware etc). That is why we hit this.
But all data is there:
dl9pf@samweis:/sys/class/sound/card0> ls -alh
insgesamt 0
drwxr-xr-x 21 root root 0 4. Aug 09:06 .
drwxr-xr-x 3 root root 0 4. Aug 09:06 ..
drwxr-xr-x 3 root root 0 4. Aug 09:06 controlC0
lrwxrwxrwx 1 root root 0 4. Aug 09:06 device -> ../../../0000:00:1f.3
drwxr-xr-x 3 root root 0 4. Aug 09:06 hwC0D0
drwxr-xr-x 3 root root 0 4. Aug 09:06 hwC0D2
-rw-r--r-- 1 root root 4,0K 4. Aug 11:21 id
drwxr-xr-x 6 root root 0 4. Aug 09:06 input36
drwxr-xr-x 6 root root 0 4. Aug 09:06 input37
drwxr-xr-x 6 root root 0 4. Aug 09:06 input38
drwxr-xr-x 6 root root 0 4. Aug 09:06 input39
drwxr-xr-x 6 root root 0 4. Aug 09:06 input40
drwxr-xr-x 6 root root 0 4. Aug 09:06 input41
drwxr-xr-x 6 root root 0 4. Aug 09:06 input42
drwxr-xr-x 6 root root 0 4. Aug 09:06 input43
-r--r--r-- 1 root root 4,0K 4. Aug 11:21 number
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D0c
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D0p
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D10p
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D3p
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D7p
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D8p
drwxr-xr-x 3 root root 0 4. Aug 09:06 pcmC0D9p
drwxr-xr-x 2 root root 0 4. Aug 11:21 power
lrwxrwxrwx 1 root root 0 4. Aug 09:06 subsystem -> ../../../../../class/sound
-rw-r--r-- 1 root root 4,0K 4. Aug 09:06 uevent
dl9pf@samweis:/sys/class/sound/card0> cd controlC0/
dl9pf@samweis:/sys/class/sound/card0/controlC0> cd ../
dl9pf@samweis:/sys/class/sound/card0> cat id
PCH
dl9pf@samweis:/sys/class/sound/card0> cat number
0
dl9pf@samweis:/sys/class/sound/card0>
--> thus now we know what /dev/snd/xyz we need to pick. (even what path ... wink, wink, device
--> hardcoding /dev/snd/by-path seems not enough
--> we need to get smarter in the way we describe what soundcard to use.
My 0,02.
TLDR:
As a user, I want to select a default or preferred output/input soundcard in the mixer, inherit a default ramping/mute mechanisms, zones, a default set of priority levels without the need to edit any file.
As a developer, I want to add a new soundcard without the need to write special config files if I use the default built-in ruleset.
As a manufacturer I want to be able to override the built-in default priorities, ramping/mute mechanisms , zones using config files.
Stephane Desneux August 3, 2018 at 10:30 PM
IMO, we should resolve that issue and open 2 other issues for GG:
one issue related to: how we launch qemu images (which params, in which context = virtualbox, qemu, ... whicvh host distro, inside or outside containers etc) => goal: have a consistent way if possible. This one is a matter of CI/Release management + Documentation IMO
another issue related to audio cards detection (4A HW detection mechanism in 4a-hal-generic): on-going efforts from @Jonathan Aillet on USB and BT audio devices may help to improve the global detection mechanism.
I'm trying to use 4A under QEMU, but opening a 4a role returns an empty device string (but with a "success" reply)
qemux86-64:~# 4a-api api ahl-4a multimedia '{"action":"open"}' Detected systemd unit file! Port detected: 1025 ON-REPLY 1:ahl-4a/multimedia: OK { "response":{ "device_uri":"" }, "jtype":"afb-reply", "request":{ "status":"success" } }
I'm running latest master as of 2 days ago, and I'm starting qemu with:
runqemu serial audio