Re: [PATCH v3 00/28] Introduce QC USB SND audio offloading support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pierre,

On 3/15/2023 7:30 AM, Pierre-Louis Bossart wrote:
Hi Wesley,

Sorry made a mistake on the diagram.  There is no connection from
SOC-USB to the APR/GLINK.  The Q6USB driver will be the one that is
going to configure some of the Q6AFE ports along withe the Q6AFE DAI
driver.

|            ASoC
----------------------------------
|  _________________________
| |sm8250 platform card     |
| |_________________________|
|         |           |
|      ___V____   ____V____
|     |Q6USB   | |Q6AFE    |  #5
|     |"codec" | |"cpu"    |
|     |________| |_________|
|         ^  ^        ^
|      #6 |  |________|
|      ___V____     |
|     |SOC-USB |    |
#7    |        |    |
----->|________|    |
---                 |
| |                 |
| |    _____________V________
| |   |APR/GLINK             |
| |   |______________________|
| |              ^
| | #8           |
| |   ___________V___________
| |->|audio DSP              |
|    |_______________________|
|
|



Makes sense now, thank you for the clarification.

I'll have to dig more in this 'soc-usb' block, it's clearly a key
component that will have to maintain a consistent state across two
different parts of the stack and deal with probe/remove/shutdown.

My initial thought was to add a 'DSP offload' PCM to the USB card, you
added a "USB offload" PCM to the DSP card. Nice logical swap!

Your proposal might be easier in practice since there's typically a
vendor-specific configuration file (UCM or custom) file for the DSP,
where USB information can be added.

It's more problematic to change a generic USB card as we know it today
and bolt vendor-specific DSP information on top.

The only open I have with your option is that there are still two
control paths to e.g. set the volume. It would be so much easier for
userspace if there was a single volume control no matter what path is
used for data, or make sure the kcontrols are 'mirrored' somehow. If we
found a way to address this issue that would be ideal.


Got it.  Let me look to see if that is something we can address/add.  I
think the current implementation is that USB SND will expose some mixer
controls based on the UAC descriptor parsing.  Then when they want to
change the volume (for example) it will result in a USB SETUP transaction.

So USB SND will eventually be the entity controlling these changes.

That's probably ok then, am I getting this right that the the DSP card
would not expose any USB-related kcontrols then, i.e. the ONLY path to
change volumes, etc.,  would through the regular USB card kcontrols?

That would limit the changes in the platform sound card to the addition
of a PCM USB device.

Yes, that's correct. There won't be any exposed USB volume controls from the DSP card.

Thanks
Wesley Cheng



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux