OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: virtio-snd: Adding support for audio controls


  Hi,

> The `type` field contains the value type for this specific control.
> Controls can have the following value types:

> SNDRV_CTL_ELEM_TYPE_INTEGER
>   32-bit integer values.
> SNDRV_CTL_ELEM_TYPE_INTEGER64
>   64-bit integer values.

Should we make SNDRV_CTL_ELEM_TYPE_INTEGER 64bit and drop
SNDRV_CTL_ELEM_TYPE_INTEGER64?  I guess alsa has both for
"historical reasons", I see little reason to have both for
a new interface.

> SNDRV_CTL_ELEM_ACCESS_READ
>   The driver can read the value of the control.
> SNDRV_CTL_ELEM_ACCESS_WRITE
>   The driver can write (change) the value of the control.
> SNDRV_CTL_ELEM_ACCESS_VOLATILE
>   Control value may be changed without a notification. (Applications
>   should poll such a control constantly.)

Hmm, is there something like "can change with notification"?

/me thinks about volume controls.  In case the pcm stream and volume
control is handled on the device (host) side by a sound daemon like
pulseaudio the volume could change because someone tweaks it using
pavucontrol.  It is probably useful to notify the driver (guest) in
case that happens ...

> The `name` field contains the name identifier string (up to 44 bytes
> including the terminating 0). ALSA classifies the role of a control by
> its name. This can be problematic for systems without ALSA.

I think it would be useful to have a role enum instead (or in addition
to the text label).

take care,
  Gerd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]