Re: [RFC PATCH v2 20/22] sound: usb: Prevent starting of audio stream if in use

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

 



Hi Pierre,

On 2/7/2023 5:29 AM, Pierre-Louis Bossart wrote:


On 2/6/23 19:15, Wesley Cheng wrote:
Hi Pierre,

On 1/26/2023 8:12 AM, Pierre-Louis Bossart wrote:


On 1/25/23 21:14, Wesley Cheng wrote:
With USB audio offloading, an audio session is started from the ASoC
platform sound card and PCM devices.  Likewise, the USB SND path is
still
readily available for use, in case the non-offload path is desired.  In
order to prevent the two entities from attempting to use the USB bus,
introduce a flag that determines when either paths are in use.

If a PCM device is already in use, the check will return an error to
userspace notifying that the stream is currently busy.  This ensures
that
only one path is using the USB substream.

It's good to maintain mutual exclusion, but it's still very hard for an
application to figure out which card can be used when.

Returning -EBUSY is not super helpful. There should be something like a
notification or connection status so that routing decisions can be made
without trial-and-error.


The USB offload driver does have access to the USB substream that is
being utilized/offloaded.  Maybe in addition to this check, we can also
set the PCM runtime state as well (for that particular substream)?  That
way userspace can fetch information about if the stream is busy or not.

You're missing the point. When a card is exposed but the PCM devices may
or may not be usable (consuming data with no sound rendered or returning
an error), it's much better to provide a clear connection status to
userspace.

Let me give you an example. Intel drivers can expose 3 HDMI/DP PCM
devices. Userspace has no idea which one to use, so there's a jack
control that tells userspace whether there is a receiver connected so
that the audio server can use the relevant PCM device.

Audio routing based on trial and error is really problematic, errors can
happen but they should be exceptional (e.g. xruns), not a means of
driver-userspace communication on the device status.

Thanks for clarifying. The example helped me understand a bit more on how the potential use of the SND control interface. Since we're dealing with multiple sound cards here (platform sound card (offload) and USB SND card (legacy)), what do you think about creating a SND control on both the USB backend (platform card) and the USB SND card listing the PCM device status?

That way at least userspace can have the information about which PCM dev (USB substream) is available (and not offloaded, or vice versa). So the USB SND control will contain the PCM devices (exposed by the card) and if any are offloaded (if so mark them as unavailable). Likewise, for the USB backend, if the legacy path is being used, mark them as unavailable for offloading.

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