Unknown Audio sink device : 'usbaudio'

tortoisedoc · 8 May 2022 08:57

REPRODUCIBILITY: Always
OS VERSION: 4.4.0.58 (Vanha Rauma)
HARDWARE: XPeria 10 II / 0.0.2.97
UI LANGUAGE: German
REGRESSION: Unknown

DESCRIPTION:

When trying to use a cabled hands-free (from Samsung), its not taken into use and the
following error is visible in the logs:

Mai 08 11:55:17 Xperia10II-DualSIM mce[1709]: modules/audiorouting.c: audio_route_sink(): unknown audio sink device = ‘usbaudio’
Mai 08 11:55:17 Xperia10II-DualSIM mce[1709]: modules/audiorouting.c: audio_route_sink(): unknown audio sink device = ‘usbaudio’

It seems the kernel detects and mounts the device fine via hid-generic:

Mai 08 11:55:16 Xperia10II-DualSIM kernel: input: Samsung USBC Headset as /devices/platform/soc/4e00000.ssusb/4e00000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.3/0003:04E8:A051.001B/input/input35
Mai 08 11:55:16 Xperia10II-DualSIM kernel: hid-generic 0003:04E8:A051.001B: input,hidraw0: USB HID v1.11 Device [Samsung USBC Headset] on usb-xhci-hcd.0.auto-1/input3
Mai 08 11:55:16 Xperia10II-DualSIM kernel: input: Samsung USBC Headset as /devices/platform/soc/4e00000.ssusb/4e00000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.4/0003:04E8:A051.001C/input/input36
Mai 08 11:55:16 Xperia10II-DualSIM kernel: hid-generic 0003:04E8:A051.001C: input,hidraw1: USB HID v1.11 Device [Samsung USBC Headset] on usb-xhci-hcd.0.auto-1/input4

PRECONDITIONS:

A cabled head set like the one listed in the logs.

STEPS TO REPRODUCE:

Plug the head set

EXPECTED RESULT:

The headset + mic should be taken into use

ACTUAL RESULT:

Headset + mic is not taken into use

MODIFICATIONS:

N/A

ADDITIONAL INFORMATION:

The audio does work for browser things, both natively as well as android side.
Calling seems to be diverted to some other place, tho.

Line in mce:

github.com

sailfishos/mce/blob/master/modules/audiorouting.c#L214

    
      
          */
          static void audio_route_sink(ohm_decision_t *ohm)
          {
             /* Lookup audio route id from sink device name.
              *
              * Note: For the purposes of mce device names
              * "xxx" and "xxxforcall" are considered equal.
              */
             for( int i = 0; ; ++i ) {
                 if( !route_lut[i].device ) {
                     mce_log(LL_WARN, "unknown audio sink device = '%s'", ohm->device);
                     audio_route = route_lut[i].route;
                     break;
                 }
          
          
       int n = strlen(route_lut[i].device);
          
          
       if( strncmp(route_lut[i].device, ohm->device, n) )
                     continue;
          
          
       const char *e = &ohm->device[n];

MCE audio routing LUT is missing usbaudio

github.com

sailfishos/mce/blob/master/modules/audiorouting.c#L117

    
      
          
          
    // sentinel
              { 0,         DF_NONE,    '-', 0 }
          };
          
          
/** Lookup table for mce audio route from sink device reported by ohmd */
          static const struct
          {
              const char        *device;
              audio_route_t      route;
          } route_lut[] = {
              { "bta2dp",           AUDIO_ROUTE_HEADSET, },
              { "bthfp",            AUDIO_ROUTE_HEADSET, },
              { "bthsp",            AUDIO_ROUTE_HEADSET, },
              { "earpiece",         AUDIO_ROUTE_HANDSET, },
              { "earpieceandtvout", AUDIO_ROUTE_HANDSET, },
              { "fmtx",             AUDIO_ROUTE_UNDEF,   },
              { "headphone",        AUDIO_ROUTE_UNDEF,   },
              { "headset",          AUDIO_ROUTE_HEADSET, },
              { "ihf",              AUDIO_ROUTE_SPEAKER, },
              { "ihfandbthsp",      AUDIO_ROUTE_SPEAKER, },

tortoisedoc · 8 May 2022 09:20

EDIT : found it! It appears usbaudio is disabled by default

from /etc/pulse/xpolicy.conf.d/usbaudio.conf

OLD ========================================

EDIT : found the reason, the routing lut does not list a usb entry:

github.com

sailfishos/mce/blob/master/modules/audiorouting.c#L117

    
      
          
          
    // sentinel
              { 0,         DF_NONE,    '-', 0 }
          };
          
          
/** Lookup table for mce audio route from sink device reported by ohmd */
          static const struct
          {
              const char        *device;
              audio_route_t      route;
          } route_lut[] = {
              { "bta2dp",           AUDIO_ROUTE_HEADSET, },
              { "bthfp",            AUDIO_ROUTE_HEADSET, },
              { "bthsp",            AUDIO_ROUTE_HEADSET, },
              { "earpiece",         AUDIO_ROUTE_HANDSET, },
              { "earpieceandtvout", AUDIO_ROUTE_HANDSET, },
              { "fmtx",             AUDIO_ROUTE_UNDEF,   },
              { "headphone",        AUDIO_ROUTE_UNDEF,   },
              { "headset",          AUDIO_ROUTE_HEADSET, },
              { "ihf",              AUDIO_ROUTE_SPEAKER, },
              { "ihfandbthsp",      AUDIO_ROUTE_SPEAKER, },

How to test this?
EDIT2 : of course the kernel could also expose the device as “headset” instead of “usbaudio”; wonder if there is a way to override this… the “usbaudio” is not used in the kernel sources, so it must be a driver / udev thing. It seems to be also not coming from the udev…and also pulseaudio from sfos repo has no reference to it. So what is left is the driver. However, I can see an issue here : Setting “any” usbaudio to headset might potentially be misleading. So overriding the usbaudio depending on the device might still be the better option (dont know if its possible via UDEV?)
EDIT3 : the plot thickens, as the DBus seems to be involved as well:

github.com

sailfishos/mce/blob/master/modules/audiorouting.c#L412

    
      
          
          
        self->fields |= field_lut[i].field;
                  break;
              }
          
          
    return ack;
          }
          
          
/** Parse all decision fields from dbus message iterator
           */
          static bool ohm_decision_parse(ohm_decision_t *self, DBusMessageIter *arr)
          {
              bool ack = false;
          
          
    DBusMessageIter str, var;
          
          
    while( !mce_dbus_iter_at_end(arr) ) {
                  const char *key  = 0;
                  if( !mce_dbus_iter_get_struct(arr, &str) )
                      goto EXIT;
                  if( !mce_dbus_iter_get_string(&str, &key) )

Bingo

signal time=1652004862.539113 sender=:1.69 → destination=(null destination) serial=655 path=/com/nokia/policy/info; i
string “1”
array [
string “usbaudio”
]
signal time=1652004862.539113 sender=:1.69 → destination=(null destination) serial=655 path=/com/nokia/policy/info; interface=com.nokia.policy; member=info
string “1”
array [
string “usbaudio”
]
method return time=1652004862.539880 sender=:1.1 → destination=:1.69 serial=9154 reply_serial=654
boolean true
signal time=1652004862.549283 sender=:1.3 → destination=(null destination) serial=1582 path=/org/nemomobile/Route/Manager; interface=org.nemomobile.Route.Manager; member=AudioRouteChanged
string “usbaudio”
uint32 9

Question is now, what issues this /com/nokia/policy/info call? MCE? UDev? Systemd?

The path here does not seem to be listed:

…but thanks to qdbus I can see that 1.26 points indeed to (surprise) pulseaudio:

:1.26
org.PulseAudio1
org.pulseaudio.Server

github.com

sailfishos/pulseaudio-policy-enforcement/blob/master/src/dbusif.c#L35

    
      
          #define ADMIN_DBUS_MANAGER          "org.freedesktop.DBus"
          #define ADMIN_DBUS_PATH             "/org/freedesktop/DBus"
          #define ADMIN_DBUS_INTERFACE        "org.freedesktop.DBus"
          
          
#define ADMIN_NAME_OWNER_CHANGED    "NameOwnerChanged"
          #define ADMIN_GET_NAME_OWNER        "GetNameOwner"
          
          
#define POLICY_DBUS_INTERFACE       "com.nokia.policy"
          #define POLICY_DBUS_MYPATH          "/com/nokia/policy/enforce/pulseaudio"
          #define POLICY_DBUS_MYNAME          "com.nokia.policy.pulseaudio"
          #define POLICY_DBUS_PDPATH          "/com/nokia/policy"
          #define POLICY_DBUS_PDNAME          "org.freedesktop.ohm"
          
          
#define POLICY_DECISION             "decision"
          #define POLICY_STREAM_INFO          "stream_info"
          #define POLICY_ACTIONS              "audio_actions"
          #define POLICY_STATUS               "status"
          
          
#define PROP_ROUTE_SINK_TARGET      "policy.sink_route.target"
          #define PROP_ROUTE_SINK_MODE        "policy.sink_route.mode"
          #define PROP_ROUTE_SINK_HWID        "policy.sink_route.hwid"

But from where is this usbaudio obtained?

Hmm found this article : PulseAudio under the hood
which mentions device.form_factor

Sources and sinks may have “device.form_factor” property. Form factor is a short string describing device type, e.g. “handset”, “headset”, “speaker”, or “microphone”.
apparently, pulseaudio considers also the UDEV property SOUND_FORM_FACTOR

github.com

sailfishos/pulseaudio/blob/master/src/modules/udev-util.c#L245

    
      
          
          
if (!pa_proplist_contains(p, PA_PROP_DEVICE_SERIAL))
              if ((v = udev_device_get_property_value(card, "ID_SERIAL")) && *v)
                  pa_proplist_sets(p, PA_PROP_DEVICE_SERIAL, v);
          
          
if (!pa_proplist_contains(p, PA_PROP_DEVICE_CLASS))
              if ((v = udev_device_get_property_value(card, "SOUND_CLASS")) && *v)
                  pa_proplist_sets(p, PA_PROP_DEVICE_CLASS, v);
          
          
if (!pa_proplist_contains(p, PA_PROP_DEVICE_FORM_FACTOR))
              if ((v = udev_device_get_property_value(card, "SOUND_FORM_FACTOR")) && *v)
                  pa_proplist_sets(p, PA_PROP_DEVICE_FORM_FACTOR, v);
          
          
/* This is normally not set by the udev rules but may be useful to
           * allow administrators to overwrite the device description.*/
          if (!pa_proplist_contains(p, PA_PROP_DEVICE_DESCRIPTION))
              if ((v = udev_device_get_property_value(card, "SOUND_DESCRIPTION")) && *v)
                  pa_proplist_sets(p, PA_PROP_DEVICE_DESCRIPTION, v);
          
          
r = 0;

flypig · 23 May 2022 22:14

Thanks for looking in to this so deeply @tortoisedoc. I’ve created an internal but report about it and tagged it as tracked. Any additional info you can find on it would also be useful.

tortoisedoc · 24 May 2022 03:08

Youre welcome. I wonder if its “only” a matter of udev not correctly labelling the device once hid-generic kicks in.