From: Ralph Ronnquist Date: Sat, 29 Apr 2023 07:31:23 +0000 (+1000) Subject: clenup and improve X-Git-Url: https://git.rrq.au/?a=commitdiff_plain;h=47fd32a8313ee5ea784a96c2c3af0cb5681bc41e;p=rrq%2Fnewlisp%2Falsa-dispatcher.git clenup and improve --- diff --git a/alsa-dispatcher.8.adoc b/alsa-dispatcher.8.adoc index 0ea690b..3261edb 100644 --- a/alsa-dispatcher.8.adoc +++ b/alsa-dispatcher.8.adoc @@ -61,14 +61,14 @@ The first line in the example asserts that "dispatch" is the default PCM. I.e. that playback directed to "default" should be passed on to "dispatch". -The lines below declares the "dispatch" PCM to have its playback -stream directed to the command _/usr/local/bin/alsa-dispatcher_ -via a pipe (that is where *alsa-dispatcher* is for this example), -and the "dispatch" PCM capture stream is sourced from _plughw_ (i.e. -the default sound card). +The rest of the example declares the "dispatch" PCM to be an "asym" +that has the playback stream directed via a pipe to the command +_/usr/bin/alsa-dispatcher_ (which is where *alsa-dispatcher* is +installed in this example), and further it has the capture stream +sourced from _plughw_ (i.e. the default sound card). Note that the playback PCM explicitly declares the stream -characteristica (format, channels and rate) used up by +characteristics (format, channels and rate) as used by *alsa-dispatcher*. === About $HOME/.alsa-dispatcher @@ -91,7 +91,7 @@ The example _$HOME/.alsa-dispatcher_ nominates _bt_ as the first ALSA PCM to try, then the _usb_ device and the _plughw_ as the third and last option. It's an imagined setup with a bluetooth device _bt_ that should have priority when in use, next a USB sound card _usb_ as -secondary option when in use, and thirdly the default sound card +secondary option when in use, and third the default sound card _plughw_. Thus, *alsa-dispatcher* will try to direct playback to _bt_ first. If @@ -101,13 +101,13 @@ playback to _plughw_ (i.e. the default sound card). == NOTES -*alsa-dispatcher* keeps playback channeling to a selected endpoint as -long as that is available. If the endpoint goes away, or the -*alsa-dispatcher* program is killed, that channeling is interrupted. -Then the original sound source (eg a browser) may establish a new -playback sink, which would caue a new *alsa-dispatcher* to run through -the priority list again to pick the first option available in the then -current audio context. +*alsa-dispatcher* keeps channeling playback to a selected endpoint as +long as that remains available. If the endpoint goes away (or the +*alsa-dispatcher* program is killed) that channeling is interrupted. +The original sound source (eg a browser) may then establish a new +playback sink, which would cause a new *alsa-dispatcher* to run +through the priority list again to pick the first option available in +the then current audio context. The program is an embedded _newlisp_ script of manageable size that links up with _libasound.so_ for ALSA API actions.