Re: [PATCH v24 12/34] ASoC: doc: Add documentation for SOC USB

Amadeusz Sławiński
2024-08-06T14:58:08Z

On 8/1/2024 3:17 AM, Wesley Cheng wrote:
> With the introduction of the soc-usb driver, add documentation highlighting
> details on how to utilize the new driver and how it interacts with
> different components in USB SND and ASoC. It provides examples on how to
> implement the drivers that will need to be introduced in order to enable
> USB audio offloading.
>
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---

(...)

> +
> +One potential use case would be to support USB audio offloading, which is
> +an implementation that allows for an external DSP on the SoC to handle the
> +transfer of audio data over the USB bus. This would let the main
> +processor to stay in lower power modes for longer durations. The following

*duration

(...)

> +
> +In order to account for conditions where driver or device existence is
> +not guaranteed, USB SND exposes snd_usb_rediscover_devices() to resend the
> +connect events for any identified USB audio interfaces. Consider the
> +the following situtation:

*situation

> +USB Offload Related Kcontrols
> +=============================
> +Details
> +-------
> +A set of kcontrols can be utilized by applications to help select the proper sound
> +devices to enable USB audio offloading. SOC USB exposes the get_offload_dev()
> +callback that designs can use to ensure that the proper indices are returned to the
> +application.

At the moment I only see getter below, how does application set it?

> +
> +Implementation
> +--------------
> +
> +**Example:**
> +
> + **Sound Cards**:
> +
> + ::
> +
> + 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
> + SM8250-MTP-WCD9380-WSA8810-VA-DMIC
> + 1 [Seri ]: USB-Audio - Plantronics Blackwire 3225 Seri
> + Plantronics Plantronics Blackwire 3225 Seri at usb-xhci-hcd.1.auto-1.1, full sp
> + 2 [C320M ]: USB-Audio - Plantronics C320-M
> + Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full speed
> +
> + **USB Sound Card** - card#1:
> +
> + ::
> +
> + USB Offload Playback Route PCM#0 -1, -1 (range -1->255)
> +
> + **USB Sound Card** - card#2:
> +
> + ::
> +
> + USB Offload Playback Route PCM#0 0, 1 (range -1->255)
> +
> +The above example shows a scenario where the system has one ASoC platform card
> +(card#0) and two USB sound devices connected (card#1 and card#2). When reading
> +the available kcontrols for each USB audio device, the following kcontrol lists
> +the mapped offload path for the specific device:
> +
> + "USB Offload Playback Route#*"
> +
> +The kcontrol is indexed, because a USB audio device could potentially have
> +several PCM devices. The above kcontrols are defined as:
> +
> + - ``USB Offload Playback Route PCM`` **(R)**: Returns the ASoC platform sound
> + card and PCM device index. The output "0, 1" (card index, PCM device index)
> + signifies that there is an available offload path for the USB SND device
> + through card#0-PCM device#1. If "-1, -1" is seen, then no offload path is
> + available for the USB SND device.
> +

That's better, although I'm still not convinced end users care where
offload happens.

Few questions though, so I'm sure I understand how it works:
Does "0, 1" in this case means that if you try to open device 1 on card
0, you won't be able to do it, because it is offloading USB?

In case it is "-1, -1" is there a chance that it can change?