qemu: opening 4a role returns empty device string (bad audio dev detection)

Description

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

 

Environment

QEMU

Attachments

2

Activity

Show:

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 on USB and BT audio devices may help to improve the global detection mechanism.

Fixed

Details

Assignee

Reporter

Fix versions

Labels

Contract ID

Components

Affects versions

Priority

Created August 3, 2018 at 8:12 AM
Updated October 1, 2018 at 9:14 PM
Resolved August 30, 2018 at 8:47 AM

Flag notifications