Message-ID: <2f16d312-381e-8d34-894c-5bd02a645d68@quicinc.com>
Date:   Mon, 13 Feb 2023 12:12:01 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [RFC PATCH v2 20/22] sound: usb: Prevent starting of audio stream
 if in use
Content-Language: en-US
To:     Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        <srinivas.kandagatla@linaro.org>, <mathias.nyman@intel.com>,
        <perex@perex.cz>, <lgirdwood@gmail.com>, <andersson@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <gregkh@linuxfoundation.org>,
        <Thinh.Nguyen@synopsys.com>, <broonie@kernel.org>,
        <bgoswami@quicinc.com>, <tiwai@suse.com>, <robh+dt@kernel.org>,
        <agross@kernel.org>
CC:     <devicetree@vger.kernel.org>, <alsa-devel@alsa-project.org>,
        <linux-arm-msm@vger.kernel.org>, <linux-usb@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <quic_jackp@quicinc.com>,
        <quic_plai@quicinc.com>
References: <20230126031424.14582-1-quic_wcheng@quicinc.com>
 <20230126031424.14582-21-quic_wcheng@quicinc.com>
 <557f8f76-38f5-5e07-905e-774e03120bd2@linux.intel.com>
 <b26c9e4c-5a9c-a2ff-19a7-78419c6b81df@quicinc.com>
 <b532bf7b-e1fb-3a9d-1b88-02f3159be47d@linux.intel.com>
 <60e42db4-1bbc-beea-d87d-6f93871b70c7@quicinc.com>
 <2c398ffb-6dd8-d43a-f99c-2033519a36be@linux.intel.com>
From:   Wesley Cheng <quic_wcheng@quicinc.com>
In-Reply-To: <2c398ffb-6dd8-d43a-f99c-2033519a36be@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Pierre,

On 2/13/2023 7:22 AM, Pierre-Louis Bossart wrote:
> 
> 
> On 2/11/23 03:52, Wesley Cheng wrote:
>> 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.
> 
> We definitively need a control to indicate that a PCM offload device is
> available or not.
> There's still a very large open with the notion of having separate cards
> for the same audio device. Not only would it duplicate the control parts
> for e.g. volume control, but it would introduce the need to tag devices
> across two cards are being the same physical device.

The volume control would still be done through the card that is exposed 
by the USB SND card (even for the offload path)[no vol control option 
for the USB device on the platform card].

In the last discussion, you did mention that maybe we can tag the 
offload path as the "power saving" option for a particular USB stream. 
Although I'm not sure how intricate the logic is, but if userspace marks 
to use the power saving path, then would it already know which card and 
PCM devices are involved?

Although, that part is missing, ie to select the card and pcm device 
that we want to offload.  It may be possible to do this with another 
control on the USB ASoC backend driver.  I believe the audio DSP can 
support device selection.

> I still think the least-bad option is to have a single card and an
> optional PCM device for offload.

This is most likely the end goal, but as mentioned previously, its going 
to be a large effort to slowly decouple some of the PCM related 
operations from USB SND.  IMO, that would most likely be another 
significant patch series in itself.

Thanks
Wesley Cheng