Google TV Remote Controls built-in mic is not detected

[bam80]

There are a lot of Remotes on the market following Google TV Remote Controls Reference Design.
All (most) of them have built-in mic.

Unfortunately, I didn't find a way to make use of the mic in linux.
Any advise?

My Ugoos BT Remote Control UR02 clone has following info:

[UR02]# info A4:C1:38:6A:9E:37 
Device A4:C1:38:6A:9E:37 (public)
	Name: UR02
	Alias: UR02
	Appearance: 0x0180 (384)
	Paired: yes
	Bonded: yes
	Trusted: yes
	Blocked: no
	Connected: yes
	WakeAllowed: no
	LegacyPairing: no
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
	UUID: Unknown                   (00001920-0000-1000-8000-00805f9b34fb)
	UUID: Vendor specific           (00010203-0405-0607-0809-0a0b0c0d1912)
	UUID: Vendor specific           (ab5e0001-5a21-4f05-bc7d-af01f617b664)
	Modalias: bluetooth:v0508p1980d0000
	ManufacturerData.Key: 0x005d (93)
	ManufacturerData.Value:
  55 66                                            Uf              
	AdvertisingFlags:
  05                                               .               
	Battery Percentage: 0x51 (81)

Please let me know if I can provide more info.
Thank you.

@Vudentz
@frederic you have been referenced (thanks @oddsolutions) as one of those who did the mic linux port attempts, so tagging you too. Any input is welcomed.

[bam80]

The remote's mic follows "Google Voice over BLE spec" (seems not available publicly officially).

Some parts of the spec can still be found in different sources:

• https://download.csdn.net/download/swlyy1986/61771336 (needs registration to get a full copy)
• Ohsung C314 Remote Controller User Manual
  • (the same manual in PDF, better formatting)
• IR/BLE Remote Contorl of Humax D’live, technical specification

From the spec:

GATT profile UUIDS for ATV Voice Service

Type	Short-form	UUID	Properties
ATV Voice Service	ATVV_SERVICE_UUID	AB5E0001-5A21-4F05-BC7D-AF01F617B664
Write Characteristic	ATVV_CHAR_TX	AB5E0002-5A21-4F05-BC7D-AF01F617B664	Write without Response
Read Characteristic	ATVV_CHAR_AUDIO	AB5E0003-5A21-4F05-BC7D-AF01F617B664	Notify
Control Characteristic	ATVV_CHAR_CTL	AB5E0004-5A21-4F05-BC7D-AF01F617B664	Notify

As we see, the ATVV_SERVICE_UUID doesn't get recognized:

$ btmgmt info <RCU's MAC>
...
UUID: Vendor specific (ab5e0001-5a21-4f05-bc7d-af01f617b664)

That may be part of the reason why we don't see the service's Characteristics advertised in the output (Write/Read/Control).

[bam80]

Some essential RCU <-> STB (Set-Top-Box) conversation Flow charts from the manuals:

3.11 - ATV Voice initialization (Capability)

a) After the Remote Control device is paired and connected, the STB will send it a
command to get capabilities of the Remote Control.
b) This command will be sent via the ATVV_CHAR_TX characteristic.
c) The Remote Control should then respond back with its capabilities using
ATVV_CHAR_CTL notification.
d) Flow chart

3.12 – Voice Search initiated by the Remote Control (On-request, legacy)

a) For Voice function, it is recommended to be within 10meters from the receiver.
b) Distance between mouth and microphone should be between 5 to 30cm.
c) If [ASSISTANT] key is pressed, the Remote Control sends the START_SEARCH command first followed by the HID_KEY_EVENT to the STB and the STB sends back the MIC_OPEN command to the Remote Control.
d) The green led turns on, the Remote Control sends the AUDIO_START command and transmits the voice data for 15secs timeout duration.
e) After timeout duration or the Remote Control receives the MIC_CLOSE command from the STB, the Remote Control sends the AUDIO_STOP command to the STB and the green led goes off.
f) Flow chart.

Note: The “On-request” assistant interaction model must be supported by all Remote Control and it should be used by default before any other interaction model is negotiated by GET_CAPS , CAPS_RESP messages exchange.

[bam80]

Even before it all was standardized, there were Android TV devices on the market bundled with voice remote controls.
Among them are ADT-1 development kit, Nexus Player, Nvidia Shield TV.

Here how they were implemented:

So for audio streaming, either you:

• use a custom L2CAP channel or a custom GATT service, this requires a custom android service app and/or modifications to Bluedroid to handle those, it will need a way to inject audio stream as ALSA, most probably with a "loop" audio device driver,
• declare audio as custom HID reports, this way, Bluedroid injects them back to the kernel, then add a custom HID driver that processes these reports and exposes an audio device.

Audio over BLE is not standard, so all implementations do not do the actual same thing.
In Nexus Player case, implementation uses HID: It streams an ADPCM audio stream, chunked in HID reports. There is a special HID driver "hid-atv-remote.c" in Android linux kernel that exposes an ALSA device in addition to input device. Bluedroid has no information about audio, all it does is forwarding HID reports from BLE to UHID.

For Nvidia Shield TV, remote's Android kernel mic audio implementation is here:
https://github.com/LineageOS/android_kernel_nvidia_nvidia/blob/lineage-22.1/drivers/hid/hid-atv-jarvis.c
It was later partially ported upstream to Linux kernel, but for Game Controller only, which doesn't have the mic:
https://github.com/torvalds/linux/blob/master/drivers/hid/hid-nvidia-shield.c

Before-mentioned initial ADT-1/Nexus Player mic driver apparently already does all the heavy-lifting for us:
https://github.com/LineageOS/android_kernel_nvidia_shield/blob/lineage-18.1/drivers/hid/hid-atv-remote.c

All what seems needed is to port it to main Linux and adjust for the Google Voice over BLE spec.
That hopefully shouldn't require too monumental amount of work as current remotes basically remained the same, they just became more standardized by following the Google spec. That said, audio packets format might changed a bit, needs to be clarified.

Other's more competent participants analysis of the situation is welcome.
@Vudentz

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[bam80]

I wouldn't close it, at least it contains important data I gathered..

I found a copy of the spec here on GitHub: Google Voice over BLE spec 1.0

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[bam80]

@Vudentz could we please remove the "stale" label?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[bam80]

Hmm it went stale again..
Is there a way to prevent it from the auto closing?