[pulseaudio-discuss] Man page clarifications
I'm relaying a bug comment to this list, the reporter has ideas about the PulseAudio documentation. He originally filed a bug about that when adding a pair of lines to ~/.pulse/default.pa and PulseAudio stopped working, as he was unaware that it caused /etc/pulse/default.pa not being used. I think it's healthy to get bug reports like these, could to know what confuses users and what makes PA harder to use. Bug report link: https://bugs.launchpad.net/bugs/663019 = Comment from B Bobo begins here === Hmmm, the issue I had was rather that it was not clear that the mere existence of ~/.pulse/default.pa effectively blocks the entire contents of /etc/pulse/default.pa from being used, instead of being that any configuration variable assignments in ~/.pulse/default.pa just override the corresponding variable assignments in /etc/pulse/default.pa. Personally, I think it would be make more sense from a user-perspective, and thus generate fewer support issues in the future, if pulseaudio were always to read both /etc/pulse/default.pa and ~/.pulse/default.pa, taking the values of configuration variables from both of them, with the values in ~/.pulse/default.pa overriding the values in /etc/pulse/default.pa. Actually, I think it would be clearer and more consistent for the users to have it work in the same way for all of the files in /etc/pulse/, following the pattern of system-wide defaults in /etc/, but override-able on a per-variable basis in the configuration in the user's .pulse directory. Some of the files in /etc/pulse/ are configuration scripts and the others are configuration files, but for both types it should be straightforward to make any variable assignments in the ~/.pulse/ version able to override those in the /etc/pulse version. I think the reason so many people recently seem to be getting confused and fed up with pulseaudio is that the documentation as a whole does have some issues. One of the issues is that it is often too terse in its explanations. If it were a bit less terse, I think there would be fewer users with support issues. Another issue with it is there is some inconsistency in how it refers to the same configuration-related entities in different places. I am going to mention a few here now; I wish I had the time to study it completely and identify all of the issues one by one. ==man page for default.pa== This man page has a title line referring to default.pa as a startup script, while the first paragraph refers to it as just the file. This change in terminology is potentially confusing for users. A script is a type of file, but many other things are also files, so file is ambiguous. It really would help the users if the terminology were 100% consistent. Calling it a file is too general; ditto for script; configuration script is more specific if a bit long. Whatever term is used, it needs to be used consistently. There is the same issue of less than 100% consistency for other terms used elsewhere in the pulseaudio documentation. If I had time, I would like to list them all here. It does need a careful review and some rewriting. There is also a question about the name default.pa. It is too general. It is potentially confusing for users. There surely has to be a better name for it, something more specific that would show immediately that it is actually a pulseaudio CLI script, rather than a configuration file containing variables as could easily be expected. Something like setup- script.cli perhaps ? We are used to seeing many other sorts of scripts with an appropriate suffix, e.g. startup.sh, edit-config.pl, search.py... ==man page for pulse-daemon.conf== This man page is quite confusing from the beginning because it talks about two similar terms configuration file and configuration script without explaining the difference clearly to users. It goes on to say that daemon.conf and default.pa both contain configuration directives implying they are both the same type of file, but they are not. That is unclear and extremely confusing for users. Configuration directives is too general a term to use in this context. To a user, it could mean statements from the pulseaudio CLI language, such as are used in default.pa, but in this case it doesn't mean that; it means variable assignments as used in configuration files. A bit of rewriting is required. This issue applies throughout the man pages; every page should state whether it is documenting a configuration script or a configuration file, and should remind users of what the difference is. ==man page for system.pa== Out of the four files in /etc/pulse/, there are man pages for only three of them. A man page for system.pa needs to be added. ==man page for pulse-client.conf== This page says the configuration file is a simple collection of variable declarations. Why the simple? Is the idea to make an implied comparison with complicated collections whatever they might be? Also, I think it is
Re: [pulseaudio-discuss] Man page clarifications
'Twas brillig, and David Henningsson at 21/10/10 07:49 did gyre and gimble: I'm relaying a bug comment to this list, the reporter has ideas about the PulseAudio documentation. He originally filed a bug about that when adding a pair of lines to ~/.pulse/default.pa and PulseAudio stopped working, as he was unaware that it caused /etc/pulse/default.pa not being used. I think it's healthy to get bug reports like these, could to know what confuses users and what makes PA harder to use. Bug report link: https://bugs.launchpad.net/bugs/663019 = Comment from B Bobo begins here === Hmmm, the issue I had was rather that it was not clear that the mere existence of ~/.pulse/default.pa effectively blocks the entire contents of /etc/pulse/default.pa from being used, instead of being that any configuration variable assignments in ~/.pulse/default.pa just override the corresponding variable assignments in /etc/pulse/default.pa. Hmm, default.pa is not doing variable assignments, it's a script with commands... Personally, I think it would be make more sense from a user-perspective, and thus generate fewer support issues in the future, if pulseaudio were always to read both /etc/pulse/default.pa and ~/.pulse/default.pa, taking the values of configuration variables from both of them, with the values in ~/.pulse/default.pa overriding the values in /etc/pulse/default.pa. I don't think that's possible. As I said, they are not doing variable assignments, but processing commands, in sequence. If you do some sort of auto-combining thing, then the sequence is lost and that's an important aspect. If you want to *change* /etc/pulse/default.pa, then copy it and make your alterations. If you just want to add a few custom things to the end, then do something like: .include /etc/pulse/default.pa load-module my-custom-module ... Which achieves that level of functionality. Actually, I think it would be clearer and more consistent for the users to have it work in the same way for all of the files in /etc/pulse/, following the pattern of system-wide defaults in /etc/, but override-able on a per-variable basis in the configuration in the user's .pulse directory. Some of the files in /etc/pulse/ are configuration scripts and the others are configuration files, but for both types it should be straightforward to make any variable assignments in the ~/.pulse/ version able to override those in the /etc/pulse version. This kind of setup could work for daemon.conf and client.conf as these are doing simple variable assignments, but it wouldn't work for default.pa as described above. I think the reason so many people recently seem to be getting confused and fed up with pulseaudio is that the documentation as a whole does have some issues. Personally I think the reason is more to do with poor integration in some desktops which I've been trying to solve, but I agree the documentation needs improvement too (I just expect most users not to even bother looking! Maybe I'm pessimistic tho'!) I'll try and incorporate the suggestions here into some kind of update (i've not read them all yet but certainly will when I get a sec). Thanks Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Man page clarifications
Am Donnerstag, den 21.10.2010, 08:49 +0200 schrieb David Henningsson: I'm relaying a bug comment to this list, the reporter has ideas about the PulseAudio documentation. He originally filed a bug about that when adding a pair of lines to ~/.pulse/default.pa and PulseAudio stopped working, as he was unaware that it caused /etc/pulse/default.pa not being used. I think it's healthy to get bug reports like these, could to know what confuses users and what makes PA harder to use. Bug report link: https://bugs.launchpad.net/bugs/663019 = Comment from B Bobo begins here === […] I agree that it is good to get this user feedback. Please thank B Bobo for taking the time to write this down. Could you ask him, if he is willing to provide a patch with the changes he can do. $ git config --global user.name Real name $ git config --global user.email b.b...@example.org $ git clone git://git.0pointer.de/pulseaudio.git $ cd pulseaudio $ gedit *files for manpages* $ git commit -a $ git format-patch -n # n = number of commits $ # either send those files to the mailing list http://pulseaudio.org/wiki/Community#MailingLists $ # or use git send-email Thanks, Paul signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtualbox sound management
'Twas brillig, and Fabrice Beauvir at 20/10/10 10:23 did gyre and gimble: So colin, tried but. The problem is stil here because Vbox redirect all VM on default sink and source , and I don't understand how to redirect correctly each input on each output. Well what I was suggesting that both VMs *do* output to the same sink. And also that both import for the same source but (and this is the critical thing) the source they both record from is *not* the the monitor source of the sink they are outputting to. That way both VMs output to a null sink and both VMs input from a the monitor of a *different* null sink. There is a thing I don't understand is how to redirect VM 1 sound output to VM 1 sound input using 2 sinks ? Hmm, this is different to the setup I thought you wanted? I throw you wanted to throw away the sound output and record only silence on both machines? Are you saying you want VM1 to record (via it's input) only the sounds that VM1 produces and to make VM2 record only the sounds VM2 produces? If so this can be done, but I'll wait for you to confirm that this is really what you want before describing it. If you want to just throw away all audio and record only silence (as I originally thought you did) then I've actually seen an easier way - just configure the virtual machines to use the Null Audio driver rather than the the PulseAudio driver :) So, shall I give up ? Only quitters quit :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Custom client-server communication
On Wed, 2010-10-20 at 00:17 +0100, Colin Guthrie wrote: There are likely no ways to piggy back onto the existing protocol for this kind of hacking sadly. The same mechanism is still used in latest PA, but in git master there is a dbus based protocol which I'd wager would be easier to extend. As it stands now, I do grant you that the modifications to the core are highly undesirable. I may try and factor this out but it doesn't really help you just now. I guess you'll have to use some kind of independent IPC to allow a given app to talk to your module. Thanks, that's clear enough. An independent IPC looks quite a good solution. I've spent _many_ _hours_ poring over the source to find how this should be done so it's quite a relief to know it's not possible!! ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
