diff mbox series

[2/2] ucm: docs: Add IVEchoData

Message ID 20230824213312.1258499-2-cujomalainey@chromium.org
State New
Headers show
Series None | expand

Commit Message

Curtis Malainey Aug. 24, 2023, 9:33 p.m. UTC 
From: Curtis Malainey <cujomalainey@chromium.org>

Provide a UCM value to mark devices which are needed to be opened only
for HW purposes but should not be consumed for userspace.

Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
---
 include/use-case.h | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Curtis Malainey Aug. 31, 2023, 5:06 p.m. UTC | #1 
Curtis Malainey | Chrome OS Audio Senior Software Engineer |
cujomalainey@google.com | Sound Open Firmware Lead


On Sat, Aug 26, 2023 at 4:31 AM Jaroslav Kysela <perex@perex.cz> wrote:
>
> On 24. 08. 23 23:33, cujomalainey@chromium.org wrote:
> > From: Curtis Malainey <cujomalainey@chromium.org>
> >
> > Provide a UCM value to mark devices which are needed to be opened only
> > for HW purposes but should not be consumed for userspace.
>
> It would be probably better to describe this in the standard ALSA PCM API than
> UCM. If the device is special, applications without UCM should be also allowed
> to identify them.
>
>                                 Jaroslav

Would something like an additional device class and a format subclass
be acceptable?

Curtis
Jaroslav Kysela Aug. 31, 2023, 7:59 p.m. UTC | #2 
On 31. 08. 23 19:06, Curtis Malainey wrote:
> Curtis Malainey | Chrome OS Audio Senior Software Engineer |
> cujomalainey@google.com | Sound Open Firmware Lead
> 
> 
> On Sat, Aug 26, 2023 at 4:31 AM Jaroslav Kysela <perex@perex.cz> wrote:
>>
>> On 24. 08. 23 23:33, cujomalainey@chromium.org wrote:
>>> From: Curtis Malainey <cujomalainey@chromium.org>
>>>
>>> Provide a UCM value to mark devices which are needed to be opened only
>>> for HW purposes but should not be consumed for userspace.
>>
>> It would be probably better to describe this in the standard ALSA PCM API than
>> UCM. If the device is special, applications without UCM should be also allowed
>> to identify them.
>>
>>                                  Jaroslav
> 
> Would something like an additional device class and a format subclass
> be acceptable?

The device class extension sounds good.

I don't know details for the format extension - does app require to set 
hw_params ? If yes, is the goal to prevent standard applications to set the 
hw_params ? If no, the format bitmask may be set to zero, thus hw_params will 
always fail.

					Jaroslav
diff mbox series

Patch

diff --git a/include/use-case.h b/include/use-case.h
index 3c7c0a26..3d629667 100644
--- a/include/use-case.h
+++ b/include/use-case.h
@@ -387,6 +387,12 @@  int snd_use_case_get_list(snd_use_case_mgr_t *uc_mgr,
  *	  device with the same parameters it opens the source device with.
  *   - EDIDFile
  *      - Path to EDID file for HDMI devices
+ *   - IVDataEcho
+ *      - Used only on devices pointed to by EchoReferenceDev. Used to mark
+ *        references that might be lower quality (e.g. reduced bit depth) as
+ *        they are intended for a HW feature and not userspace consumption.
+ *        These PCMs still need to be opened by userspace but are not
+ *        recommended for consumption.
  *   - JackCTL
  *      - jack control device name
  *   - JackControl