[RFC PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology

[Mark Brown]

On Thu, Sep 03, 2020 at 04:32:22PM -0500, Pierre-Louis Bossart wrote:
> On 9/3/20 3:42 PM, Jaroslav Kysela wrote:

> > 
> > Only my 2 cents: It's just another word combo. See bellow for sources for others.
> > 
> > I would prefer probably provider/consumer . It sounds more technic.

> Thanks Jaroslav for chiming in. I had a similar set of comments in internal
> reviews, but we didn't really have any consensus and I have not seen good
> guidance specifically for clocks.

> Provider/consumer is typically used for discrete data exchange with some
> sort of locking and buffer fullness metric, but for clocks we'd want
> something that hints at one device following the timing defined by another.

> "follow" or "track" seem clearer than 'consume' IMHO, but I will side with
> the majority, this is an RFC which can be modified at will.

Producer/consumer is already quite widely used for clocks (possibly
following the regulator API which was templated off the clock API and
uses consumer).  The follow/track stuff definitely seems awkward to me.
Have we seen any movement from anyone like CODEC vendors on this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200904/410a054b/attachment.sig>