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@xxxxxxxxxxxxxxxxx > >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > > > _______________________________________________ > Speakup mailing list > Speakup@xxxxxxxxxxxxxxxxx > 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 _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
