Unknown Audio sink device : 'usbaudio'

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:

  1. 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:

MCE audio routing LUT is missing usbaudio

1 Like

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

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

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

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

How to test this? :thinking:
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:

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

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

2 Likes

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.

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

1 Like