On Tue, Mar 25, 2025 at 04:18:03PM -0700, Wesley Cheng wrote:
> On 3/25/2025 2:24 AM, Stephan Gerhold wrote:
> > On Tue, Mar 18, 2025 at 05:51:32PM -0700, Wesley Cheng wrote:
> >> The QC ADSP is able to support USB playback endpoints, so that the main
> >> application processor can be placed into lower CPU power modes. This adds
> >> the required AFE port configurations and port start command to start an
> >> audio session.
> >>
> >> Specifically, the QC ADSP can support all potential endpoints that are
> >> exposed by the audio data interface. This includes isochronous data
> >> endpoints, in either synchronous mode or asynchronous mode. In the latter
> >> case both implicit or explicit feedback endpoints are supported. The size
> >> of audio samples sent per USB frame (microframe) will be adjusted based on
> >> information received on the feedback endpoint.
> >>
> >> Some pre-requisites are needed before issuing the AFE port start command,
> >> such as setting the USB AFE dev_token. This carries information about the
> >> available USB SND cards and PCM devices that have been discovered on the
> >> USB bus. The dev_token field is used by the audio DSP to notify the USB
> >> offload driver of which card and PCM index to enable playback on.
> >>
> >> Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
> >> ---
> >> sound/soc/qcom/qdsp6/q6afe-dai.c | 60 +++++++
> >> sound/soc/qcom/qdsp6/q6afe.c | 192 ++++++++++++++++++++++-
> >> sound/soc/qcom/qdsp6/q6afe.h | 36 ++++-
> >> sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c | 23 +++
> >> sound/soc/qcom/qdsp6/q6dsp-lpass-ports.h | 1 +
> >> sound/soc/qcom/qdsp6/q6routing.c | 32 +++-
> >> 6 files changed, 341 insertions(+), 3 deletions(-)
> >>
> [...]
> >> diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c
> >> index 90228699ba7d..b7439420b425 100644
> >> --- a/sound/soc/qcom/qdsp6/q6routing.c
> >> +++ b/sound/soc/qcom/qdsp6/q6routing.c
> >> @@ -435,6 +435,26 @@ static struct session_data *get_session_from_id(struct msm_routing_data *data,
> >>
> >> return NULL;
> >> }
> >> +
> >> +static bool is_usb_routing_enabled(struct msm_routing_data *data)
> >> +{
> >> + int i;
> >> +
> >> + /*
> >> + * Loop through current sessions to see if there are active routes
> >> + * to the USB_RX backend DAI. The USB offload routing is designed
> >> + * similarly to the non offload path. If there are multiple PCM
> >> + * devices associated with the ASoC platform card, only one active
> >> + * path can be routed to the USB offloaded endpoint.
> >> + */
> >> + for (i = 0; i < MAX_SESSIONS; i++) {
> >> + if (data->sessions[i].port_id == USB_RX)
> >> + return true;
> >> + }
> >> +
> >> + return false;
> >> +}
> >
> > What is different about USB_RX compared to other output ports we have in
> > Q6AFE? Obviously, we can only play one stream on an output port. But
> > doesn't the ADSP mix streams together when you have multiple routes?
> >
>
> This patch will limit the USB_RX from being able to be mixed to multiple
> q6adm paths.
>
> > Also, this doesn't actually check for *active* routes only. It just
> > looks if any other MultiMedia DAI is configured to output to USB_RX.
> > That doesn't mean they will ever be active at the same time.
> >
>
> Yes, the main reason being that that is the mechanism we use to populate
> the active offload path within the USB SND card mixer.
>
> > I might for example want to have MultiMedia1 and MultiMedia2 both
> > configured to output to USB_RX. Let's assume MultiMedia1 is a normal PCM
> > DAI, MultiMedia2 is a compress offload DAI. When I want to playback
> > normal audio, I go through MultiMedia1, when I want to play compressed
> > audio, I go through MultiMedia2. Only one of them active at a time.
> > Why can't I set this up statically in the mixers?
> >
> > If you confirm that it is really impossible to have multiple streams
> > mixed together to the USB_RX output in the ADSP, then this should be a
> > runtime check instead when starting the stream IMO.
> >
>
> We can have multiple streams being mixed together, but it will get
> confusing because it changes the definition that we had discussed about in
> the past about the overall design for the interaction w/ userspace.
> Although we (QC) only support a single USB audio device for offloading,
> there could be other situations where the audio DSP can support multiple
> devices. The assumption is that each MM path is assigned to a USB device.
>
Are you referring to the "USB Offload Playback Route PCM#*" mixers here?
They could just refer to first of the configured MM paths, if someone
decides to route multiple paths to the USB backend. Looking at
q6usb_update_offload_route(), I think the implementation does that
already.
I think it's fine that the userspace API for automatically "probing" the
PCM device supports only a single path to the USB backend. But if
someone wants to bypass the automatic probing and configure a more
advanced setup, do we need to forbid that?
Asked differently: what would happen if we remove this check here and
handle USB_RX like any other Q6AFE output port? Would anything break for
the userspace interface?
> [...]
> >
> > Are you planning to send follow-up patches for USB recording offload
> > (USB_TX) later? Me and Luca successfully used your series to playback
> > voice call audio via the ADSP to an USB headset, recording would be also
> > needed to use this fully. :-)
> >
>
> Yes, I will follow up after getting the bulk of the changes for playback
> merged first. The TX side changes should be minimal, and require only
> small updates.
>
Thanks, sounds good!
Stephan
