| Message ID | 20240507195116.9464-35-quic_wcheng@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Introduce QC USB SND audio offloading support | expand |
On 5/7/24 14:51, Wesley Cheng wrote: > In order to allow userspace/applications know about USB offloading status, > expose a sound kcontrol that fetches information about which sound card > index is associated with the ASoC platform card supporting offloading. In > the USB audio offloading framework, the ASoC BE DAI link is the entity > responsible for registering to the SOC USB layer. SOC USB will expose more > details about the current offloading status, which includes the USB sound > card and USB PCM device indexes currently being used. > > It is expected for the USB offloading driver to add the kcontrol to the > sound card associated with the USB audio device. An example output would > look like: > > tinymix -D 1 get 'USB Offload Playback Capable Card' > 0 (range -1->32) You already gave the following examples in patch 29: " USB offloading idle: tinymix -D 0 get 'USB Offload Playback Route Status' -->-1, -1 (range -1->32) USB offloading active(USB card#1 pcm#0): tinymix -D 0 get 'USB Offload Playback Route Status' -->1, 0 (range -1->32) " Can you clarify how many controls there would be in the end? Also isn't tinymix -D N going to give you the controls for card N?
Hi Pierre, On 5/7/2024 2:37 PM, Pierre-Louis Bossart wrote: > > > On 5/7/24 14:51, Wesley Cheng wrote: >> In order to allow userspace/applications know about USB offloading status, >> expose a sound kcontrol that fetches information about which sound card >> index is associated with the ASoC platform card supporting offloading. In >> the USB audio offloading framework, the ASoC BE DAI link is the entity >> responsible for registering to the SOC USB layer. SOC USB will expose more >> details about the current offloading status, which includes the USB sound >> card and USB PCM device indexes currently being used. >> >> It is expected for the USB offloading driver to add the kcontrol to the >> sound card associated with the USB audio device. An example output would >> look like: >> >> tinymix -D 1 get 'USB Offload Playback Capable Card' >> 0 (range -1->32) > > You already gave the following examples in patch 29: > > " > USB offloading idle: > tinymix -D 0 get 'USB Offload Playback Route Status' > -->-1, -1 (range -1->32) > > USB offloading active(USB card#1 pcm#0): > tinymix -D 0 get 'USB Offload Playback Route Status' > -->1, 0 (range -1->32) > " > > Can you clarify how many controls there would be in the end? For USB offload situations, there will be a set of controls for playback status and playback select. The offload jack will also be there to tell us if there is an offload path available for the platform ASoC sound card. > Also isn't tinymix -D N going to give you the controls for card N? > Yes, since the offload portion is handled as a DPCM DAI link to the platform ASoC card, it will be included as a kcontrol for that. Thanks Wesley Cheng
Hi Pierre, On 5/8/2024 12:41 PM, Wesley Cheng wrote: > Hi Pierre, > > On 5/7/2024 2:37 PM, Pierre-Louis Bossart wrote: >> >> >> On 5/7/24 14:51, Wesley Cheng wrote: >>> In order to allow userspace/applications know about USB offloading >>> status, >>> expose a sound kcontrol that fetches information about which sound card >>> index is associated with the ASoC platform card supporting >>> offloading. In >>> the USB audio offloading framework, the ASoC BE DAI link is the entity >>> responsible for registering to the SOC USB layer. SOC USB will >>> expose more >>> details about the current offloading status, which includes the USB >>> sound >>> card and USB PCM device indexes currently being used. >>> >>> It is expected for the USB offloading driver to add the kcontrol to the >>> sound card associated with the USB audio device. An example output >>> would >>> look like: >>> >>> tinymix -D 1 get 'USB Offload Playback Capable Card' >>> 0 (range -1->32) >> >> You already gave the following examples in patch 29: >> >> " >> USB offloading idle: >> tinymix -D 0 get 'USB Offload Playback Route Status' >> -->-1, -1 (range -1->32) >> >> USB offloading active(USB card#1 pcm#0): >> tinymix -D 0 get 'USB Offload Playback Route Status' >> -->1, 0 (range -1->32) >> " >> >> Can you clarify how many controls there would be in the end? > > For USB offload situations, there will be a set of controls for playback > status and playback select. The offload jack will also be there to tell > us if there is an offload path available for the platform ASoC sound card. > >> Also isn't tinymix -D N going to give you the controls for card N? >> > > Yes, since the offload portion is handled as a DPCM DAI link to the > platform ASoC card, it will be included as a kcontrol for that. > > Thanks > Wesley Cheng > > Sorry for responding again. I read your email again, and wanted to also add that aside from the above, which are all within the ASoC layer, as we discussed previously, we should have a kcontrol in the USB SND card to determine if there is an ASoC platform card capable of offloading. This is also available from the SND card created by the USB audio device. Thanks Wesley Cheng
>>>> It is expected for the USB offloading driver to add the kcontrol to the >>>> sound card associated with the USB audio device. An example output >>>> would >>>> look like: >>>> >>>> tinymix -D 1 get 'USB Offload Playback Capable Card' >>>> 0 (range -1->32) >>> >>> You already gave the following examples in patch 29: >>> >>> " >>> USB offloading idle: >>> tinymix -D 0 get 'USB Offload Playback Route Status' >>> -->-1, -1 (range -1->32) >>> >>> USB offloading active(USB card#1 pcm#0): >>> tinymix -D 0 get 'USB Offload Playback Route Status' >>> -->1, 0 (range -1->32) >>> " >>> >>> Can you clarify how many controls there would be in the end? >> >> For USB offload situations, there will be a set of controls for >> playback status and playback select. The offload jack will also be >> there to tell us if there is an offload path available for the >> platform ASoC sound card. >> >>> Also isn't tinymix -D N going to give you the controls for card N? >>> >> >> Yes, since the offload portion is handled as a DPCM DAI link to the >> platform ASoC card, it will be included as a kcontrol for that. >> >> Thanks >> Wesley Cheng >> >> > > Sorry for responding again. I read your email again, and wanted to also > add that aside from the above, which are all within the ASoC layer, as > we discussed previously, we should have a kcontrol in the USB SND card > to determine if there is an ASoC platform card capable of offloading. > This is also available from the SND card created by the USB audio device. That makes sense: if the application wanted to use a given endpoint, it could check if there is a 'better' path exposed by another card. It'd be a lot easier than reading controls from random cards. Was this part of this patchset or more of an idea for a future addition?
Hi Pierre, On 5/9/2024 6:11 AM, Pierre-Louis Bossart wrote: > >>>>> It is expected for the USB offloading driver to add the kcontrol to the >>>>> sound card associated with the USB audio device. An example output >>>>> would >>>>> look like: >>>>> >>>>> tinymix -D 1 get 'USB Offload Playback Capable Card' >>>>> 0 (range -1->32) >>>> >>>> You already gave the following examples in patch 29: >>>> >>>> " >>>> USB offloading idle: >>>> tinymix -D 0 get 'USB Offload Playback Route Status' >>>> -->-1, -1 (range -1->32) >>>> >>>> USB offloading active(USB card#1 pcm#0): >>>> tinymix -D 0 get 'USB Offload Playback Route Status' >>>> -->1, 0 (range -1->32) >>>> " >>>> >>>> Can you clarify how many controls there would be in the end? >>> >>> For USB offload situations, there will be a set of controls for >>> playback status and playback select. The offload jack will also be >>> there to tell us if there is an offload path available for the >>> platform ASoC sound card. >>> >>>> Also isn't tinymix -D N going to give you the controls for card N? >>>> >>> >>> Yes, since the offload portion is handled as a DPCM DAI link to the >>> platform ASoC card, it will be included as a kcontrol for that. >>> >>> Thanks >>> Wesley Cheng >>> >>> >> >> Sorry for responding again. I read your email again, and wanted to also >> add that aside from the above, which are all within the ASoC layer, as >> we discussed previously, we should have a kcontrol in the USB SND card >> to determine if there is an ASoC platform card capable of offloading. >> This is also available from the SND card created by the USB audio device. > > That makes sense: if the application wanted to use a given endpoint, it > could check if there is a 'better' path exposed by another card. It'd be > a lot easier than reading controls from random cards. > > Was this part of this patchset or more of an idea for a future addition? Its part of this patchset. Please refer to patch#34. The mixer_usb_offload is initialized by the offload entity residing in USB SND (qc_usb_audio_offload), and will add it to the sound card associated with the USB device. Thanks Wesley Cheng
diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig index 5cc3eaf53e6b..1228be3c1f83 100644 --- a/sound/usb/Kconfig +++ b/sound/usb/Kconfig @@ -176,6 +176,16 @@ config SND_BCD2000 To compile this driver as a module, choose M here: the module will be called snd-bcd2000. +config SND_USB_QC_OFFLOAD_MIXER + bool "Qualcomm USB Audio Offload mixer control" + help + Say Y to enable the Qualcomm USB audio offloading mixer controls. + This exposes an USB offload capable kcontrol to signal to + applications about which platform sound card can support USB + audio offload. This can potentially be used to fetch further + information about the offloading status from the platform sound + card. + config SND_USB_AUDIO_QMI tristate "Qualcomm Audio Offload driver" depends on QCOM_QMI_HELPERS && SND_USB_AUDIO && USB_XHCI_SIDEBAND && SND_SOC_USB diff --git a/sound/usb/qcom/Makefile b/sound/usb/qcom/Makefile index a81c9b28d484..eada5cd7b71f 100644 --- a/sound/usb/qcom/Makefile +++ b/sound/usb/qcom/Makefile @@ -1,2 +1,6 @@ snd-usb-audio-qmi-objs := usb_audio_qmi_v01.o qc_audio_offload.o -obj-$(CONFIG_SND_USB_AUDIO_QMI) += snd-usb-audio-qmi.o \ No newline at end of file +obj-$(CONFIG_SND_USB_AUDIO_QMI) += snd-usb-audio-qmi.o + +ifneq ($(CONFIG_SND_USB_QC_OFFLOAD_MIXER),) +snd-usb-audio-qmi-objs += mixer_usb_offload.o +endif \ No newline at end of file diff --git a/sound/usb/qcom/mixer_usb_offload.c b/sound/usb/qcom/mixer_usb_offload.c new file mode 100644 index 000000000000..cd6e5600e795 --- /dev/null +++ b/sound/usb/qcom/mixer_usb_offload.c @@ -0,0 +1,65 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#include <linux/usb.h> + +#include <sound/core.h> +#include <sound/control.h> +#include <sound/soc-usb.h> + +#include "../card.h" +#include "../mixer.h" +#include "../usbaudio.h" + +#include "mixer_usb_offload.h" + +static int +snd_usb_offload_available_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct device *sysdev = snd_kcontrol_chip(kcontrol); + int ret; + + ret = snd_soc_usb_device_offload_available(sysdev); + ucontrol->value.integer.value[0] = ret < 0 ? -1 : ret; + + return ret < 0 ? ret : 0; +} + +static int snd_usb_offload_available_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + uinfo->count = 1; + uinfo->value.integer.min = -1; + uinfo->value.integer.max = SNDRV_CARDS; + + return 0; +} + +static const struct snd_kcontrol_new snd_usb_offload_available_ctl = { + .iface = SNDRV_CTL_ELEM_IFACE_CARD, + .access = SNDRV_CTL_ELEM_ACCESS_READ, + .name = "USB Offload Playback Capable Card", + .info = snd_usb_offload_available_info, + .get = snd_usb_offload_available_get, +}; + +/** + * snd_usb_offload_create_ctl() - Add USB offload bounded mixer + * @chip - USB SND chip device + * + * Creates a sound control for a USB audio device, so that applications can + * query for if there is an available USB audio offload path, and which + * card is managing it. + */ +int snd_usb_offload_create_ctl(struct snd_usb_audio *chip) +{ + struct usb_device *udev = chip->dev; + + return snd_ctl_add(chip->card, + snd_ctl_new1(&snd_usb_offload_available_ctl, + udev->bus->sysdev)); +} diff --git a/sound/usb/qcom/mixer_usb_offload.h b/sound/usb/qcom/mixer_usb_offload.h new file mode 100644 index 000000000000..0efda52e92b6 --- /dev/null +++ b/sound/usb/qcom/mixer_usb_offload.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#ifndef __USB_OFFLOAD_MIXER_H +#define __USB_OFFLOAD_MIXER_H + +#if IS_ENABLED(CONFIG_SND_USB_QC_OFFLOAD_MIXER) +int snd_usb_offload_create_ctl(struct snd_usb_audio *chip); +#else +static inline int snd_usb_offload_create_ctl(struct snd_usb_audio *chip) +{ + return -ENODEV; +} +#endif +#endif /* __USB_OFFLOAD_MIXER_H */ diff --git a/sound/usb/qcom/qc_audio_offload.c b/sound/usb/qcom/qc_audio_offload.c index 1a45bc289f90..aeea224bba70 100644 --- a/sound/usb/qcom/qc_audio_offload.c +++ b/sound/usb/qcom/qc_audio_offload.c @@ -37,6 +37,7 @@ #include "../pcm.h" #include "../power.h" +#include "mixer_usb_offload.h" #include "usb_audio_qmi_v01.h" /* Stream disable request timeout during USB device disconnect */ @@ -1660,6 +1661,8 @@ static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip) uaudio_qdev->last_card_num = chip->card->number; snd_soc_usb_connect(usb_get_usb_backend(udev), sdev); + snd_usb_offload_create_ctl(chip); + mutex_unlock(&chip->mutex); mutex_unlock(&qdev_mutex);
In order to allow userspace/applications know about USB offloading status, expose a sound kcontrol that fetches information about which sound card index is associated with the ASoC platform card supporting offloading. In the USB audio offloading framework, the ASoC BE DAI link is the entity responsible for registering to the SOC USB layer. SOC USB will expose more details about the current offloading status, which includes the USB sound card and USB PCM device indexes currently being used. It is expected for the USB offloading driver to add the kcontrol to the sound card associated with the USB audio device. An example output would look like: tinymix -D 1 get 'USB Offload Playback Capable Card' 0 (range -1->32) Ths example signifies that card#0 has an USB offload capable path available. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> --- sound/usb/Kconfig | 10 +++++ sound/usb/qcom/Makefile | 6 ++- sound/usb/qcom/mixer_usb_offload.c | 65 ++++++++++++++++++++++++++++++ sound/usb/qcom/mixer_usb_offload.h | 17 ++++++++ sound/usb/qcom/qc_audio_offload.c | 3 ++ 5 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 sound/usb/qcom/mixer_usb_offload.c create mode 100644 sound/usb/qcom/mixer_usb_offload.h