Settings report incorrect Microphone device names

[Simon Fels]

When opening the "Camera & microphone" settings in the webbrowser-app I get the following list of Microphone devices I can select one from:

- Default
- Droid source primary
- Null input

The last two ones are incorrect and should never reach the user. The user doesn't know what to do with those names.

Either we're missing a proper alias in pulseaudio or webbrowser-app needs to add them.

[Simon Fels (morphis)]

There are two things:

1. The incorrect named "Droid source primary" element which is something we could easily fix from pulseaudio by just adding a better description for the source.

2. The null input should be never listed as its useless for the user and just used internally to allow proper routing for Bluetooth audio devices. Whoever (I suspect webbrowser-app) lists the devices here needs to filter that device out. There are a number of different hings for the source element we can use for that

Source #3
 State: SUSPENDED
 Name: source.fake.sco
 Description: Null Input
 Driver: module-null-source.c
 Sample Specification: s16le 1ch 8000Hz
 Channel Map: mono
 Owner Module: 8
 Mute: no
 Volume: mono: 65536 / 100% / 0.00 dB
         balance 0.00
 Base Volume: 65536 / 100% / 0.00 dB
 Monitor of Sink: n/a
 Latency: 0 usec, configured 0 usec
 Flags: DECIBEL_VOLUME LATENCY
 Properties:
  device.description = "Null Input"
  device.class = "abstract"
  device.icon_name = "audio-input-microphone"
 Formats:
  pcm

[David Barth (dbarth)]

@morphis: Is there a better API to call to get the list of "user" visible audio inputs instead? or a well-known filter to apply to get those. I image most apps will want that list, whereas system level components will be the only one interested in the full extent list.

[Olivier Tilloy (osomon)]

Oxide is responsible for listing the audio capture devices. See https://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/core/api/oxideqmediacapturedevices.cc#L163 for implementation details.

Chromium exposes the following attributes for each device:

 - id (string)
 - name (string)
 - input (AudioDeviceParameters)
   - sample_rate (int)
   - channel_layout (int)
   - frames_per_buffer (int)
   - effects (int)

The null input device would need to be filtered out based on any combination of these attributes, while making sure that no other valid device can be incorrectly filtered out.

[Simon Fels (morphis)]

@David: Not sure, but you can take a look at

$ pactl list sources

That lists all properties pulse reports for the source devices. However from the Android side (that is where we're reading the list of available devices from) we only get 'primary' as the name of the source and not further information.

With that we could fix the description of the pulse source to remove 'Droid' from the name and just have something like 'primary source'. What you also have to respect is that the primary source has different ports

Source #1
 State: SUSPENDED
 Name: source.primary
 Description: Droid source primary
 Driver: module-droid-card.c
 Sample Specification: s16le 2ch 44100Hz
 Channel Map: front-left,front-right
 Owner Module: 5
 Mute: no
 Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
         balance 0.00
 Base Volume: 65536 / 100% / 0.00 dB
 Monitor of Sink: n/a
 Latency: 0 usec, configured 0 usec
 Flags: HARDWARE HW_MUTE_CTRL DECIBEL_VOLUME
 Properties:
  device.description = "Droid source primary"
  droid.hw_module = "primary"
  device.icon_name = "audio-card"
  droid.audio_source = "default"
 Ports:
  input-builtin_mic: Input from builtin mic (priority: 300)
  input-bluetooth_sco_headset: Input from bluetooth sco headset (priority: 200)
  input-wired_headset: Input from wired headset (priority: 500, not available)
  input-voice_call: Input from voice call (priority: 200)
  input-back_mic: Input from back mic (priority: 200)
  input-default: Input from default (priority: 200)
  input-parking: Parking port (priority: 50)
 Active Port: input-builtin_mic
 Formats:
  pcm

So the primary source can be the builtin-mic, a connect HFP headset, audio coming from a call, ... Which port is active depends on different factors in the system. We should also look into gnome-control-center and see how the audio configuration is handled there.

[Olivier Tilloy (osomon)]

Additionally, the device names should be localized, as they are user-facing strings.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Ubuntu Touch is no longer supported.