All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: broonie@kernel.org, tiwai@suse.com, perex@perex.cz,
	amadeuszx.slawinski@linux.intel.com, linux-sound@vger.kernel.org,
	gregkh@linuxfoundation.org, quic_wcheng@quicinc.com,
	mathias.nyman@linux.intel.com
Subject: Re: [RFC 00/15] ALSA/ASoC: USB Audio Offload
Date: Thu, 10 Apr 2025 12:24:48 +0200	[thread overview]
Message-ID: <87v7rcwbyn.wl-tiwai@suse.de> (raw)
In-Reply-To: <20250409110731.3752332-1-cezary.rojewski@intel.com>

On Wed, 09 Apr 2025 13:07:15 +0200,
Cezary Rojewski wrote:
> 
> Note: this series is based on Mark's broonie/for-next. The xHCI
> dependency is missing so it won't compile.  Goal of this RFC is
> discussing the direction of sound/usb changes.
> 
> Note #2: Why exclude xHCI?  Current form of xhci-sideband.c [1] does not
> fare well with Intel's hardware design for USB Audio Offload feature.
> The production shape for usb/xHCI subjects is being discussed with
> Mathias.  Once we're ready, I'll share the rest.
> 
> Note #3: this series does _NOT_ aim to block QCOM's equivalent series
> [2].  The team does acknowledge that we came the "table" late.  At the
> same time, we're prepared to help QCOM switch to the presented sound/usb
> approach if that would benefit the framework and its users as a whole.
> Make it part of this very series if need be.
> 
> 
> 
> Apart from changes to sound/usb, the patchset contains exemplary
> ASoC-based, offload-aware USB driver and a small sound card on the
> avs-driver side to show how card/dai_link initialization looks like.
> 
> In short, USB Audio Offload functionality lowers CPU usage when
> streaming PCM over a USB Audio-Class device.  It has been first
> introduced in xHCI 1.2 release and is described in section 7.9 [3].
> Once hardware is prepared with hw_params(), all the USB endpoints
> operations e.g.: start, stop, submitting URBs, are performed
> internally, by the hardware and AudioDSP firmware.  Software driver
> shall not intervene.
> 
> Startup flow from:
> 
> 	usb_pcm_open()
> 	usb_pcm_hw_params()
> 		snd_usb_endpoint_open()
> 	usb_pcm_prepare()
> 		usb_set_interface()
> 		snd_usb_endpoint_start()
> 	usb_pcm_trigger(cmd: START/STOP etc.)
> 
> reduced to:
> 
> 	usb_pcm_open()
> 	usb_pcm_hw_params()
> 		snd_usb_endpoint_open()
> 	usb_pcm_prepare()
> 		usb_set_interface()

Hmm, how can it be?  The start of EP at prepare stage is done only
conditionally for non-lowlatency or implicit-feedback mode, for
example.

> Handlers such as ack(), sync_stop(), pointer(), delay() are not used
> here too.  The AudioDSP driver will handle pointer(), rest is
> firmware/hardware responsibility.
> 
> 
> There's a hefty number of limitations, most importantly:
> 
> 1) typically 2 USB devices tops, rest go the classic (non-offload) path
> 2) AUDIOSTREAMING interfaces only, MIDI not.  While not an interface
>    type, Media (sound/usb/media) unsupported either
> 3) simple PCM, UAC_FORMAT_TYPE_I_PCM only
> 
> Current patchset shows this in form of 'udev->audsb_capable' field.
> True if xHCI sideband reasource has been assigned to the device.  The
> filtering is code is not part of the patchset.
> 
> Important to highlight, 1) means both, offload-aware and offload-unaware
> drivers could be utilized simultaneously on the system in runtime.
> Opportunistically few devices would be controlled by the offload-aware
> driver, whereas everything else by the offload-unaware one.  This
> differs from existing HDAudio Controller driver situation where either
> classic, snd_hda_intel driver takes complete control -or- the
> offload-aware snd_soc_avs driver.
> In short, once all Audio Sideband resources are depleted, classic
> sound/usb/card.c driver manages whatever comes next:
> 
> 	snd_usb_audio (offload un-aware, sound/usb/card.c)
> 	snd_soc_usb_codec (offload aware, sound/soc/codecs/usb.c)
> 
> 
> The design goals:
> 	- make ASoC first class citizen of sound/usb
> 	- re-use code found in sound/usb, mimic HDAudio integration in ASoC:
> 	  small sound/soc/codecs/hda.c driver leveraging power of entire
> 	  sound/pci/hda/
> 	- no shared control over a USB device, either snd_usb_audio or
> 	  its ASoC equivalent takes control of the device
> 
> To do that, major tasks are identified:
> 
> a) On ASoC side 'struct snd_card' is part of 'struct snd_soc_card' and
> is managed by the framework.  Similar situation with 'struct snd_pcm'
> and rtd->pcm.  To keep the teardown path sane, drop card->private_free()
> and pcm->private_free() usage.

Well, this is a generic problem of ASoC framework.
I believe this should be better handled in ASoC core side at first.
e.g. the card object could be created at the very first step of the
snd_soc_card creation, too (but without the actual slot assignment or
device creation).

> b) To initialize ASoC components/DAI properly, PCM capabilities should be
> known up-front.  To do that, existing USB card probe() has to be split.
> From one-stage to two-stage process:
> 
> 	- look ahead and parse usb_interface descriptors for PCM endpoints
> 	  but do not create any PCMs (sound devices) yet
> 	- create all PCMs based on obtained ->pcm_list and follow with
> 	  MIDI/mixers/media
> 
> Such approach allows to feed DAIs proper data even when a valid
> sound-card pointer is not yet present - the initialization occurs before
> snd_soc_bind_card() is called.
 
This one is another thing that is needed to adjust for ASoC
framework.  But when snd_card object is available, this can be
resolved automatically, too?  e.g. snd_pcm object or such can be
created at that point.  The actual device registration is done anyway
later via snd_device_register() call.


thanks,

Takashi

> Point a) is scaled for all three "domains" of sound/usb: chip, stream
> and quirks.  That's why there total of 6 commits doing that job.  First
> implement, then switch.  Everything that follows is, in my opinion,
> self-explanatory.  No need to repeat commit messages.
> 
> 
> [1]: https://lore.kernel.org/all/20250319005141.312805-2-quic_wcheng@quicinc.com/
> [2]: https://lore.kernel.org/all/20250319005141.312805-1-quic_wcheng@quicinc.com/
> [3]: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
> 
> 
> Cezary Rojewski (15):
>   ALSA: usb: Move media-filters to the media code
>   ALSA: usb: Drop private_free() usage for card and pcms
>   ALSA: usb: Relocate the usbaudio header file
>   ALSA: usb: Implement two-stage quirk applying mechanism
>   ALSA: usb: Implement two-stage stream creation mechanism
>   ALSA: usb: Implement two-stage chip probing mechanism
>   ALSA: usb: Switch to the two-stage chip probing
>   ALSA: usb: Switch to the two-stage stream creation
>   ALSA: usb: Switch to the two-stage quirk applying
>   ALSA: usb: Export PCM operations
>   ALSA: usb: Export usb_interface driver operations
>   ALSA: usb: Export card-naming procedure
>   ALSA: usb: Add getters to obtain endpoint information
>   ASoC: codecs: Add USB-Audio driver
>   ASoC: Intel: avs: Add USB machine board
> 
>  include/linux/usb.h                         |  15 +
>  include/linux/usb/ch9.h                     |  11 +
>  sound/usb/usbaudio.h => include/sound/usb.h |  53 +-
>  include/sound/usb_offload.h                 |  46 +
>  sound/soc/codecs/Kconfig                    |   6 +
>  sound/soc/codecs/Makefile                   |   2 +
>  sound/soc/codecs/usb.c                      | 441 +++++++++
>  sound/soc/intel/avs/boards/Kconfig          |   8 +
>  sound/soc/intel/avs/boards/Makefile         |   2 +
>  sound/soc/intel/avs/boards/usb.c            | 115 +++
>  sound/usb/caiaq/device.h                    |   2 +-
>  sound/usb/card.c                            | 946 +++++++++++++-------
>  sound/usb/card.h                            |   4 +-
>  sound/usb/clock.c                           |   2 +-
>  sound/usb/endpoint.c                        |   2 +-
>  sound/usb/format.c                          |   2 +-
>  sound/usb/helper.c                          |   2 +-
>  sound/usb/implicit.c                        |   2 +-
>  sound/usb/media.c                           |   8 +-
>  sound/usb/midi.c                            |   2 +-
>  sound/usb/midi.h                            |   2 +
>  sound/usb/midi2.c                           |   2 +-
>  sound/usb/midi2.h                           |   1 +
>  sound/usb/misc/ua101.c                      |   2 +-
>  sound/usb/mixer.c                           |   2 +-
>  sound/usb/mixer_quirks.c                    |   2 +-
>  sound/usb/mixer_s1810c.c                    |   2 +-
>  sound/usb/mixer_scarlett.c                  |   2 +-
>  sound/usb/mixer_scarlett2.c                 |   2 +-
>  sound/usb/mixer_us16x08.c                   |   2 +-
>  sound/usb/pcm.c                             | 161 +++-
>  sound/usb/power.c                           |   2 +-
>  sound/usb/proc.c                            |   2 +-
>  sound/usb/quirks.c                          | 203 +++--
>  sound/usb/quirks.h                          |   6 +
>  sound/usb/stream.c                          | 217 +++--
>  sound/usb/stream.h                          |   2 +
>  sound/usb/usx2y/us122l.c                    |   2 +-
>  sound/usb/usx2y/usX2Yhwdep.c                |   1 +
>  sound/usb/usx2y/usbusx2y.h                  |   2 +-
>  sound/usb/validate.c                        |   2 +-
>  41 files changed, 1749 insertions(+), 541 deletions(-)
>  rename sound/usb/usbaudio.h => include/sound/usb.h (82%)
>  create mode 100644 include/sound/usb_offload.h
>  create mode 100644 sound/soc/codecs/usb.c
>  create mode 100644 sound/soc/intel/avs/boards/usb.c
> 
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2025-04-10 10:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 11:07 [RFC 00/15] ALSA/ASoC: USB Audio Offload Cezary Rojewski
2025-04-09 11:07 ` [RFC 01/15] ALSA: usb: Move media-filters to the media code Cezary Rojewski
2025-04-09 11:07 ` [RFC 02/15] ALSA: usb: Drop private_free() usage for card and pcms Cezary Rojewski
2025-04-09 11:07 ` [RFC 03/15] ALSA: usb: Relocate the usbaudio header file Cezary Rojewski
2025-04-09 11:07 ` [RFC 04/15] ALSA: usb: Implement two-stage quirk applying mechanism Cezary Rojewski
2025-04-09 11:07 ` [RFC 05/15] ALSA: usb: Implement two-stage stream creation mechanism Cezary Rojewski
2025-04-09 11:07 ` [RFC 06/15] ALSA: usb: Implement two-stage chip probing mechanism Cezary Rojewski
2025-04-09 11:07 ` [RFC 07/15] ALSA: usb: Switch to the two-stage chip probing Cezary Rojewski
2025-04-09 11:07 ` [RFC 08/15] ALSA: usb: Switch to the two-stage stream creation Cezary Rojewski
2025-04-09 11:07 ` [RFC 09/15] ALSA: usb: Switch to the two-stage quirk applying Cezary Rojewski
2025-04-09 11:07 ` [RFC 10/15] ALSA: usb: Export PCM operations Cezary Rojewski
2025-04-09 11:07 ` [RFC 11/15] ALSA: usb: Export usb_interface driver operations Cezary Rojewski
2025-04-09 11:07 ` [RFC 12/15] ALSA: usb: Export card-naming procedure Cezary Rojewski
2025-04-09 11:07 ` [RFC 13/15] ALSA: usb: Add getters to obtain endpoint information Cezary Rojewski
2025-04-09 11:07 ` [RFC 14/15] ASoC: codecs: Add USB-Audio driver Cezary Rojewski
2025-04-09 11:07 ` [RFC 15/15] ASoC: Intel: avs: Add USB machine board Cezary Rojewski
2025-04-09 12:10 ` [RFC 00/15] ALSA/ASoC: USB Audio Offload Greg KH
2025-04-09 13:06   ` Cezary Rojewski
2025-04-10 10:10     ` Takashi Iwai
2025-04-10 10:24 ` Takashi Iwai [this message]
2025-04-11  9:39   ` Cezary Rojewski
2025-04-15 16:15     ` Takashi Iwai
2025-04-17 10:15       ` Cezary Rojewski
2025-04-22 11:28         ` Pierre-Louis Bossart
2025-04-22 14:15           ` Cezary Rojewski
2025-04-25 16:53             ` Pierre-Louis Bossart
2025-04-11 14:04 ` Greg KH
2025-04-11 16:51   ` Cezary Rojewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v7rcwbyn.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=perex@perex.cz \
    --cc=quic_wcheng@quicinc.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.