Sink vs sync

Sun Apr 14 05:45:55 EDT 2019

Hi, Didier:

Didier Spaier writes:
> Hello Janina,
> 
> Well, I thought that "source" and "sink" rather were chosen by
> analogy with a water distribution system.
> 
Perhaps. There's certainly useful analogy comparing audio management
with water distribution.

https://codes.iccsafe.org/content/IPC2018/chapter-6-water-supply-and-distribution

Does PA explain this anywhere? As I've recently been complaining on the
Midi-Mag list, technology is notorious for poor documentation,
especially when it comes to defining its terms. I submit PA is one such
exemplary offender.

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.

> About pipewire (thanks for the info), a short look at the wiki
> makes me think that it is trying to find a niche "market" between
> JACK and PulseAudio. Anyway it will take some time before I can
> possibly consider shipping it in Slint <smile>

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.

> 
> Oh, and I have no issue with PulseAudio at all.
> So, no bye bye PulseAudio here.
> 
> Granted it can have more latency than JACK, but is not targeted
> at audiophiles.
> 
Yes, it was designed with highly limited use cases and requirements. At
the time Redhat figured it was OK to ignore professional audio
requirements, and they certainly never asked for accessibility use
cases.

By the time I knew about it, it was too late to do anything. It was
ready to ship.

We need to get into pipewire now for the reasons I explain above, not
after it ships and you decide whether or not to package it for Slink.

> BTW, the article I linked to clearly explains how to make
> JACK and PulseAudio coexist.
> 

Yes, that's a solved problem. Still, many professional audio
installations studiously avoid installing PA, e.g. CCRMA in Palo Alto,
or IRCAM in Paris. For them PA is a nuisance.

http://ccrma.stanford.edu/planetccrma/software/

Best,

Janina

> Best,
> 
> Didier
> 
> 
> On 13/04/2019 22:37, Janina Sajka wrote:
> > Indeed. Pulseaudio's use of the term "sink" is sadly ironic. To a
> > reasonably educated English speaker it' squite clearly the confusion of
> > someone who's not so well versed in English. The term they wanted is
> > "sync," as in "syncronization.," not "sink" as in the kitchen sink.
> > 
> > But, it's now possibly the case that pulseaudio itself is about to be
> > overtaken by a newer and more comprehensive specification, pipewire:
> > 
> > https://pipewire.org
> > 
> > 
> > Bye, bye, pulseaudio.
> > 
> > hth
> > 
> > Janina
> > 
> > Didier Spaier writes:
> >> Hello,
> >>
> >> On 13/04/2019 20:55, Jude DaShiell wrote:
> >>> Once pulseaudio got introduced the whole sound system due to the strange
> >>> language used with pulseaudio got lots more complex.
> >>
> >> Yes the language used by PulseAudio is not obvious (at least for someone
> >> whose native language is French). As an example I had hard time
> >> understanding what a "sink" means. But to be honest the vocabulary used
> >> by ALSA was not easy to grasp for me either. And unfortunately differs.
> >>
> >> As an aside, for people seriously wanting to know PulseAudio I highly
> >> recommend reading "PulseAudio under the hood" from Victor Gaydov:
> >> https://gavv.github.io/articles/pulseaudio-under-the-hood/
> >> It covers pretty much every topic you can think of, answers a lot of
> >> questions you may have and issues you could come across. Here is the
> >> table of contents:
> >>
> >> Preface
> >> About PulseAudio
> >> High-level components
> >> Key abstractions
> >> D-Bus API
> >> C API
> >> Protocols and networking
> >> Device drivers
> >> Sound processing
> >> Sample cache
> >> Stream management
> >> Time management
> >> Power saving
> >> Automatic setup and routing
> >> Desktop integrations
> >> Compatibility layers
> >> Server internals
> >> Module list
> >> GUI tools
> >> Command line tools
> >> Configuration
> >> Portability
> >> Example setups
> >> Example clients and modules
> >> Critique
> >>
> >> Dosed anyone knows a similar document about ALSA?
> >>
> >> Best regards
> >>
> >> Didier
> >> _______________________________________________
> >> Speakup mailing list
> >> Speakup at linux-speakup.org
> >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> > 
> _______________________________________________
> Speakup mailing list
> Speakup at linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa