Sink vs sync

[Didier Spaier]

Hi, Janina:

On 14/04/2019 11:45, Janina Sajka wrote:
> We could debate whether or not the term is apt, but the real point I'm
> making is the above. Terms need to be clearly defined. Whether it's
> audio or plumbing, it's dangerous to assume the meaning of terms will be
> self-evident.

I 150% agree as that makes things even more difficult for a non native
English reader.

As an aside, pipewire is not immune of the tendency to use terms with a
specific meaning, as e.g. "nodes" and "graphs" in:
https://github.com/PipeWire/pipewire/wiki/Audio-support

> Oh, we need to get involved sooner than shipping time. We need to make
> sure they're considering our user scenarios, use cases and requirements
> in designing the protocols. If our needs aren't spelled out, we have no
> complaint should our needs not be met in the final product.
> 
> One quick example might be remote desktop audio. If tomorrow's "ssh -x"
> invokes pipewire, it should carry at-spi info, imo, not just a screen
> binary that responds to mouse clicks.
> 
> Pipewire based web servers should be able to provide well defined
> caption and video description streams, including semantic data along
> with the primary video being served.
> 
> WebRTC implementations should be able to note who's chosen to not
> participate in feeding (or consuming) video. Participants in a WebRTC
> conference shouldn't go around assuming everyone is seeing and hearing,
> in other words. Accessibility must be built into our communication
> protocols, not just bolted on after the fact in specialized apps like
> Speakup and Emacspeak.

Certainly. I am grateful (and I guess that I am not alone) that you take
the time to state a11y related requirements and make aware of them the
development teams soon enough for so that they be fulfilled.
I'd be unable to do that, both because my knowledge in the audio and
video field is not sufficient and as being sighted I can hardly imagine
the use cases in concern and the related requirements.

Best,

Didier