Hi Pierre,
On 10/18/2023 6:47 AM, Pierre-Louis Bossart wrote:
Specifically, the QC ADSP can support all potential endpoints that are
exposed by the audio data interface. This includes, feedback endpoints
(both implicit and explicit) as well as the isochronous (data)
endpoints.
implicit feedback means support for capture. This is confusing...
I mean, a USB device can expose a capture path, but as of now, we won't
enable the offloading to the audio DSP for it. However, if we're
executing playback, and device does support implicit feedback, we will
pass that along to the audio DSP to utilize.
Not following. Implicit feedback means a capture stream *SHALL* be
started. Are you saying this capture stream is hidden and handled at the
DSP level only? If yes, what prevents you from exposing the capture
stream to userspace as well?
I must be missing something.
My understanding is that with implicit feedback endpoints, it allows for
another data endpoint in the opposite direction to be utilized as a
feedback endpoint (versus having to expose another EP, such as in the
case of explicit feedback). For example, if we are enabling the
playback path (and the device does have a capture data ep) then the data
ep used for the capture path can be used.
USB2.0 spec, section 5.12.4.3 (Implicit Feedback)
"
Two cases can arise:
• One or more asynchronous sink endpoints are accompanied by an
asynchronous source endpoint. The
data rate on the source endpoint can be used as implicit feedback
information to adjust the data rate on
the sink endpoint(s).
• One or more adaptive source endpoints are accompanied by an adaptive
sink endpoint. The source
endpoint can adjust its data rate based on the data rate received by the
sink endpoint.
"
The DSP will get this as part of the USB sync endpoint information which
it will use to enable this EP.
+static const struct snd_soc_dai_ops q6usb_ops = {
+ .probe = msm_dai_q6_dai_probe,
+ .prepare = q6afe_dai_prepare,
+ .hw_params = q6usb_hw_params,
this is rather confusing with two different layers used for hw_params
and prepare? Additional comments or explanations wouldn't hurt.
I thought this was how the ASoC design was. Each DAI defined for a
particular path has it own set of callbacks implemented to bring up any
required resources for that entity. So in this case, it initializes the
"cpu" DAI, which is the main component that handles communication with
the audio DSP.
Usually prepare and hw_params rely on the type of DAI callbacks, but
here you are mixing "q6afe" and "q6usb" which are shown in your Patch0
diagram as "cpu" and "codec" dais respectively. I don't think it's
correct to tie the two, it's a clear layering violation IMHO. The codec
dai .prepare should not invoke something that modifies the state of the
CPU dai, which should have its own .prepare callback.
OK, I think I know where the misunderstanding is. The API callback for
hw_params() that is being registered here exists in q6afe, but with the
q6usb prefix. I will fix that in the next rev.
Thanks
Wesley Cheng
