[pulseaudio-discuss] Undelivered Mail Returned to Sender
This is the mail system at host spammotel.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system lepbtetfm...@spammotel.com: host mail.niksula.hut.fi[130.233.40.6] said: 451 4.3.5 Server configuration problem (in reply to RCPT TO command) Reporting-MTA: dns; spammotel.com X-Postfix-Queue-ID: 6800E8A609D X-Postfix-Sender: rfc822; re.7UU79DD3BHVZT@spammotel.com Arrival-Date: Thu, 26 Nov 2009 18:36:27 -0500 (EST) Final-Recipient: rfc822; LEPBTETFMVBZ@spammotel.com Action: failed Status: 4.3.5 Remote-MTA: dns; mail.niksula.hut.fi Diagnostic-Code: smtp; 451 4.3.5 Server configuration problem ---BeginMessage--- users want to use one audio card Reply-To: re.7UU79DD3BHVZT Return-Path: re.7UU79DD3BHVZT Colin Guthrie wrote: This is typically a permissions problem. Does the pulse user (which IIRC is used by system mode) have permissions to open the sound devices? All right, this was it! I wish pulsaudio with multiple users was more straightforward one day. -- Tomasz Chmielewski http://wpkg.org ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ---End Message--- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Fri, Jan 1, 2010 at 3:52 AM, Bill Cox waywardg...@gmail.com wrote: Since I didn't get much response with my more polite e-mail, here's what I really think, given my current ignorance about pulseaudio... PulseAudio is cool, but I fear it's over-engineered by some Ph.D's with too much elegance in their solution, and not enough real world experience. Run as user? Really? it would be ok as long as it would support multiple users. The problem is that it doesn't care about /etc/group audio permissions and thus breaks backward compatibility with alsa. You have a few options * the easiest one is to remove pulseaudio and get audio work again as it was meant to be (which is also conform to all other unixsystems) * another way would be to run pulseaudio as system daemon (depreciated) * use alsa dmix, and configure pulseaudio to use alsa dmix. Best Regards, Markus If you think you've got a good reason to do this, is it more important than sacraficing accessibility for the blind? The worst disaster for accessibility for the blind and visually impaired has been adoption of PulseAduio by the major distros. I'm personally spending insane hours trying to fix this mess, and frankly I could use some direction. We've got Orca mostly working now, but the other essential app - speakup - is still in limbo. Now the blind community has no pull. We can't tell Ubuntu to run PulseAudio as a normal deamon. As a result, our computers come up talking but then can't talk once the user logs into gnome. This is because speakup launches a process that starts pulseaudio as the gdm user, and since that process continues forever, the gdm copy of pulseaudio never dies, and the user's gnome session gets no access to the sound card, and Orca wont talk. I just need a solution. I'm frankly hoping to get more response to this more emotional e-mail than my previous polite one. I promise to be nice once I'm convinced we're not actually letting a bunch of inexperienced coders undermine the Linux sound system, which is likely to happen once I'm no longer ignorant of what the heck this user-land stuff is all about, and when I learn how to write code that gives the blind speach on their Ctrl+Alt+F1 consoles from boot, as well as after they login. You know what it's like trying to help a blind user through e-mail to figure out what to do when the computer just stops talking? Ever try to explain to a user over the phone how to use a graphical application? It's much worse than that. The sound system needs to work at boot, when we log in, and in fact all the time. Is that too much to ask? That's what I require from Ubunut/Lucid. I'm willing to write the code to make it happen. Can anyone please advise me on what code needs to be written to get speakup and Orca to both work with pulseaudio, from boot, after logging into gnome, and on the console windows? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Switching resample_method on the fly?
On Wed, 30.12.09 03:07, Bearcat M. Şandor (bear...@feline-soul.com) wrote: Using Pulseaudio 0.9.19 on gentoo amd64 Folks, I like to use resample-method=src-snc-best-quality for music (i upsample to 192k) and resample-method=src-snc-medium-quality for flash videos and videos. Until i figure out how to upsample gstreamer and flash to 192k (the latter of which is probably not possible) how can i switch back and forh forth from src-sinc-medium-quality to src-sinc-best-quality on the fly? As tanuk correctly pointed out the infrastructure for implementing something like this is already available in the PA core. What's missing though is a module actually making use of this, a protocol extension to allow client-side control of it and finally a UI for it. It should be relatively easy to simply extend m-s-r a little to cover this too, the same way it already controls the devices and volumes for particular streams. The only hard part would be to keep proper compat with older versions of the protocol and PA. But that should be feasible too. Patches welcome. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] What is corking?
On Fri, 25.12.09 20:23, David Henningsson (launchpad@epost.diwic.se) wrote: Corking means that the application asked for the audio stream to be corked temporarily, so that data flow stops. uncorking then makes things flow again. It's mostly synonymous to application triggered pause/unpause. Instantaneous pause, i e without drain buffers first, right? No data is dropped. On tsched enabled systems the pausing should happen almost immediately, just a few safety samples later than the current hw playback index. On non-tsched systems the pausing will happen as soon as possible, i.e. with a delay of once the hw buffer size. As soon as you uncork playback starts right-away again. In both cases this is triggered by the app explicitly. Thanks, that answers some questions but also raises new ones... There are rows saying Requesting rewind due to rewrite but there are no rows following up that rewind, as seen in other logs[2]. How come? Not all the same a rewind is even possible. Second, can you (or anyone else) think of a scenario where these lines typically reoccurs frequently, or are we looking at an error, either in GStreamer[1] or in PulseAudio? It is not necessarily an error if these lines appear. For example if the client does not provide data to PA when the buffer actually runs empty but based on its own client side timing. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] PulseAudio+Bluez acting as Bluetooth stereo headset - no sound yet
Hi chaps, A happy new year to you all. I want to turn my Ubuntu-Karmic-based eee-PC into a Bluetooth stereo headset (eventually, the eee will be replaced by a car infotainment system). The eee connects via Bluetooth to a mobile phone, which acts as an audio source for the eee. The music played on the mobile is transported via Bluetooth to the eee and comes out of the eee's speakers. That's the theory. In practise, the streaming stops after 3-5 seconds and there is no sound any way. From the syslog messages (see attachment playmusic3.syslog), I see the following: - At tag ###1, pulseaudio has successfully created an audio source bluez_source.00_25_48_F5_D8_15. - At tag ###2, the audio stream seems to be set up correctly. The message is module-bluetooth-device.c: Stream properly set up, we're ready to roll!. - At tag ###3, there are some problems setting rlimit's. I guess because pulseaudio runs in a per-user session and does not have the access privileges to change the rlimit's. I assume that the problem isn't really important. - From tag ###4 to tag ###5, pulseaudio tells alsa-mixer to look at profiles. It actually finds three supported profiles: ###4a - output:analog-stereo, ###4b - output:analog-stereo+input:analog-stereo, ###4c - input:analog-stereo. *Question*: What are these ALSA profiles used for? - At tag ###6, things seem to go wrong with the message alsa-mixer.c: Unable to attach to mixer front:0: No such file or directory. But maybe this problem can be ignored, because the next line says alsa-mixer.c: Successfully attached to mixer 'hw:0'. - At tag ###7, pulseaudio seems to fall back to some default sinks and sources (module-device-restore.c comes into play). That doesn't look good. *Question*: What's going wrong here? - At tag ###8, things start to repeat and it is the same steps and message as from tag ###1. Any ideas what is going wrong in my setup? It might be a bit of a wild guess. But do I have to set a sink in my default.pa file? I have also attached my ~/.asoundrc file, the output from *pacmd list-modules*, and the output from *aplay -L*. My ~/.pulse/client.conf file is empty and ~/.pulse/daemon.conf only contains the entries *log-target = syslog* and *log-level = debug*. I don't have a ~/.pulse/default.pa file yet. All the files are in the attached tarball. Thanks for your help, Burkhard padebug.tgz Description: GNU Zip compressed data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pacmd list-sink-inputs requested latency value
Hi,
I'm trying to understand the output from pacmd.
My problem is that pacmd list-sinks outputs: configured latency: 0,00
ms; range is 56,00 .. 371,52 ms (no client connected)
And when running the test program from the bottom of this message,
pacmd list-sink-inputs always outputs requested latency: 56,00 ms.
Testing randomly I found that changing tlength =
pa_usec_to_bytes(atoi(argv[3]) * 1e3, ss), for .tlength = 2 *
pa_usec_to_bytes(atoi(argv[3]) * 1e3, ss), I always get 20 ms less
than what I would expect. So ./pulse-test 48000 2 120 makes pacmd
list-sink-inputs return requested latency: 100,00 ms.
I'm running PulseAudio 0.9.19 on openSUSE 11.2. Perhaps it's a bug
already fixed in a later versions?
Thanks.
#include stdio.h
#include pulse/simple.h
#include pulse/error.h
int main(int argc, char *argv[]) {
const pa_sample_spec ss = {
.format = PA_SAMPLE_S16LE,
.rate = atoi(argv[1]),
.channels = atoi(argv[2])
};
const pa_buffer_attr buffer_attr = {
.maxlength = -1,
.tlength = pa_usec_to_bytes(atoi(argv[3]) * 1e3, ss),
.prebuf = -1,
.minreq = -1,
.fragsize = -1
};
int error = 0;
pa_simple *s = pa_simple_new(NULL, test, PA_STREAM_PLAYBACK, NULL,
test, ss, NULL, buffer_attr, error);
printf(error: %s\n, pa_strerror(error));
sleep(15);
}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
Thanks, Colin. I can probably modify speech-dispatcher and speechdup-d to run as gdm on boot. I can probably also modify gdm code to look for speech-dispatcher and speechd-up as well, and relaunch them. It definately feels weird mucking about with the login package, though. However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are there any ways to get pulseaudio to share the sound card? If not, doesn't it make more sense to have a single pulseaudio deamon, so multiple users can share it? I'm frankly not aware of actual instances of one user listening on the mic of another, for example, nor any other actual sound system security hack in the wild. I prefer to fix problems that actually happen, rather than dream up imaginary problems and then offer complex solutions. For example, I have a real problem in that pulseaudio doesn't work with speakup and Orca at the same time, and it wont allow me to switch user and get sound as the new user. We can keep building hacks, like modifying gdm to restart yet more sound processes (speechd-up and speech-dispatcher, for example), and we could hack switch-user to do the same, or we could realize we're spending a lot of effort fixing a problem that isn't real. Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? Thanks, Bill On Thu, Dec 31, 2009 at 12:27 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Bill Cox at 31/12/09 17:13 did gyre and gimble: Thanks for the info. Is there a simple way to kill off the gdm pulseaduio when the user logs in? Some sort of hook I can tie into? It should all happen automatically: console-kit will hand over the active session to the user logging in and PA will play nicely with that. I've not looked into this in huge depth so can't really advise more than that - hopefully I'll find time to play and/or Lennart/someone else will be able to advice more practically. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
On Fri, Jan 1, 2010 at 4:58 PM, Bill Cox waywardg...@gmail.com wrote: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are they the same user id? I suspect there's something wonky occurring with ConsoleKit. See ck-history --log and ck-list-sessions. -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
No, the problem happens when I switch to a new user. On Fri, Jan 1, 2010 at 5:08 PM, Daniel Chen seven.st...@gmail.com wrote: On Fri, Jan 1, 2010 at 4:58 PM, Bill Cox waywardg...@gmail.com wrote: However, even with these changes, there are bugs due to pulseaudio's user-based structure. Today, in Karmic, if I 'switch user' to another use, my new gnome session has no sound. That's because there are two pulseaudio processes running, and the first one takes over control of the sound card and does not share. Are they the same user id? I suspect there's something wonky occurring with ConsoleKit. See ck-history --log and ck-list-sessions. -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio+Bluez acting as Bluetooth stereo headset - no sound yet
pe, 2010-01-01 kello 16:02 +0100, Burkhard Stubert kirjoitti: Hi chaps, A happy new year to you all. I want to turn my Ubuntu-Karmic-based eee-PC into a Bluetooth stereo headset (eventually, the eee will be replaced by a car infotainment system). The eee connects via Bluetooth to a mobile phone, which acts as an audio source for the eee. The music played on the mobile is transported via Bluetooth to the eee and comes out of the eee's speakers. That's the theory. In practise, the streaming stops after 3-5 seconds and there is no sound any way. From the syslog messages (see attachment playmusic3.syslog), I see the following: * At tag ###1, pulseaudio has successfully created an audio source bluez_source.00_25_48_F5_D8_15. * At tag ###2, the audio stream seems to be set up correctly. The message is module-bluetooth-device.c: Stream properly set up, we're ready to roll!. * At tag ###3, there are some problems setting rlimit's. I guess because pulseaudio runs in a per-user session and does not have the access privileges to change the rlimit's. I assume that the problem isn't really important. Correctly assumed. * From tag ###4 to tag ###5, pulseaudio tells alsa-mixer to look at profiles. It actually finds three supported profiles: ###4a - output:analog-stereo, ###4b - output:analog-stereo +input:analog-stereo, ###4c - input:analog-stereo. Question: What are these ALSA profiles used for? They are for switching the mode in which the sound card is used. Your card can be used in three modes: analog stereo out, analog stereo in, and a combination of them. There could be more on some other sound card; I think the main motivation for the profiles came from the desire to switch between stereo and surround modes. * At tag ###6, things seem to go wrong with the message alsa-mixer.c: Unable to attach to mixer front:0: No such file or directory. But maybe this problem can be ignored, because the next line says alsa-mixer.c: Successfully attached to mixer 'hw:0'. Yes, it can be ignored. The alsa mixer apparently can't be opened using the front device. I'm not sure if this is a bug in the driver, but we can use hw as well. * At tag ###7, pulseaudio seems to fall back to some default sinks and sources (module-device-restore.c comes into play). That doesn't look good. Question: What's going wrong here? Nothing is wrong. When sinks and sources are loaded, module-device-restore restores them to the same state that they had when pulseaudio was previously running. * At tag ###8, things start to repeat and it is the same steps and message as from tag ###1. Any ideas what is going wrong in my setup? There are crashes, so apparently nothing is wrong in the setup. The a2dp source is just buggy. Here are notes about each pulseaudio pid change: The log sample starts with some bluetooth activity, apparently the a2dp source is being loaded. Pulseaudio has pid 1518. After ###2 the bluetooth device module fails an assertion: Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Assertion '(size_t) decoded == a2dp-frame_length' failed at modules/bluetooth/module-bluetooth-device.c:1367, function a2dp_process_push(). Aborting. A new pulseaudio process is spawned with pid 1772. Here's a mystery: Dec 31 16:01:12 beee pulseaudio[1772]: card.c: Created 1 bluez_card.00_25_48_F5_D8_15 Dec 31 16:01:43 beee pulseaudio[2030]: module-bluetooth-device.c: Connected to the bluetooth audio service What's happening here? During 31 seconds pulseaudio pid changes from 1772 to 2030, but nothing is logged during this change. Then the same assertion failure occurs again: Dec 31 16:01:43 beee pulseaudio[2030]: module-bluetooth-device.c: Assertion '(size_t) decoded == a2dp-frame_length' failed at modules/bluetooth/module-bluetooth-device.c:1367, function a2dp_process_push(). Aborting. After that a new pulseaudio instance is spawned with pid 2060. That stays running until the end of the log sample. You seem to be running pulseaudio 0.9.19. There were some bluetooth fixes in 0.9.20; I recommend updating to 0.9.21. If the bugs are still there, file a new ticket. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
On Sat, Jan 2, 2010 at 2:21 AM, Tanu Kaskinen ta...@iki.fi wrote: pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... Can you point out to a few requests where people had serious issues with shared audio access during the last 10 years, other unix systems get along quite fine with shared support. The hacking argument is just nonsense, I highly doubt that it has any relevance for real. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Using pulseaudio with speakup
la, 2010-01-02 kello 02:56 +0100, Markus Rechberger kirjoitti: On Sat, Jan 2, 2010 at 2:21 AM, Tanu Kaskinen ta...@iki.fi wrote: pe, 2010-01-01 kello 16:58 -0500, Bill Cox kirjoitti: Anyone out there every get hacked because you shared the Alsa back-end with another user? Anyone? I don't think anyone is going to get hacked because of this - it's rather rare that you say your passwords aloud. Instead of hacking issue, it's a privacy issue on shared machines. You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem... Can you point out to a few requests where people had serious issues with shared audio access during the last 10 years, other unix systems get along quite fine with shared support. The hacking argument is just nonsense, I highly doubt that it has any relevance for real. No, I can't point out such requests. I answered your question even before you asked it, and you even quoted the answer: You can try arguing against that as long as nobody reports real cases of eavesdropping, but I think this is a rather obvious problem. Obviously you don't think it's so obvious. That's fine, we can agree to disagree. My opinion doesn't matter anyway. Personally, if I shared a computer, I would be happy to know that the other people can't eavesdrop me without root access and knowledge of how to tweak the behaviour of consolekit or hal or whatever actually does the device access control modifications. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 17, 2009 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: I don't see why anyone would want to have audio when changing to root for admin purposes. Playing music certainly does not fall under admin purposes. Ever consider what happens when a blind user switches to root, and his sound card stop speaking? This is no hypothetical situation, like someone trying to spy on me through Alsa by taking over my mike. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 6:57 AM, Lennart Poettering lenn...@poettering.net wrote: And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. How can I bypass PA on a Ubuntu Karmic or Lucid? If I disable user-land pulseaudio, several applications break, including the volume control. PulseAudio has been Vulcan mind-melded into the system. If you know of a realistic way to bypass PulseAudio, by all means, please state it! If sound were just for music, this wouldn't be a big deal. Speakup needs to route speech to the sound card, regardless of who is logged in, and in parallel with whatever music or speech they are playing. PulseAudio has broken Linux accesibility for the blind quite seriously. I'm a C coder, willing to help. Got any ideas for a solution? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 9:13 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: The Problem can be summarized in one sentence: Pulseaudio currently breaks multiuser systems and is only useful for one-user-desktop. Actually no, the exact opposite. PA works very well for multi user desktops. Hi, Col. Let me say I'm beginning to be a fan of your posts, as I read more of them. This is probably an Ubuntu issue, but in Karmic and Lucid, Switch User does not change the permissions for the sound card, and the new user will be mute. It's a fairly minor bug... the work-around is logout and log back in. IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. I'm not a bad C coder. I can patch this and make it work. But I don't want to go writing a random work-around blindly! I need advice as what the right solution is. Here's one thought, but I haven't examined the code effected. What if we allow certain users parallel access to particular sound card? Speakup launches speechd-up which launches speech-dispatcher during boot, as user 'speech-dispatcher'. If speech-dispatcher ran as gdm instead, and we allowed gdm to always access the sound card? That way, gdm would reuse speech-dispatcher's copy of pulseaudio rather than making a new one, and we'd no longer have to worry about killing gdm's copy of pulseaudio when a user logs in, or restarting it when he logs out. Is that the best way to patch this system? Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. But for you right === the exact same way it used to work. Hi, Colin. I think it is important to understand where people like Markus come from. I suspect he's completely blind. Right for him means his system talks to him at boot, in both speakup and Orca and probably a few other apps. Wrong is when the sound system stops speakup or Orca from talking. It's the ultimate show-stopper bug for the blind. Losing sound for a blind person is about as scary as a hard-disk crash - maybe worse! A blind person often has to track down a sighted person with the skills to repair his software in person. This can be a lot harder than installing a new hard drive and OS. I want to help constructively. I want to track down the problem and suggest a patch. Any guidance as to the approach to take would be very welcome - I really don't know the PulseAudio system well enough to determine the best approach. Eventually, I'll just pick one and do it, but it's worth begging for advice if I can get it! Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Lennart, let me explain how blind people use Linux. There are TWO applications in common use - Orca and Speakup. Actually, there's a third - emacspeak, but let's not go there, yet. Orca is the screen reader that you are talking about. It runs as user, and can be made to work well with PulseAudio. I've personally helped in that effort (I wrote a new pulseaudio driver for it). The other critical application is Speakup. It runs as a kernel module and speaks every bit of console output during the boot process. Many blind people rely heavily on Speakup, and only use Orca for websites that require Firefox to read. 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. Output deamons do belong in the user session, but not all speech deamons do. Speakup, in particular, is a kernel module. It's job is speaking all console output to the user. The blind don't give a hoot how we get speach from /dev/speakup_soft to the sound card. It just has to happen. Today, on every pulseaudio enabled system I know of, this does not work properly. I tried setting speakup to use alsa, and it works, right up until pulseaudio for gdm starts. After that, speakup is mute. Is there any way for pulseaudio to share the sound card with speakup/alsa? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering lenn...@poettering.net wrote: We actually cover that inside of gdm, where you can get access to the boot messages. Lennart Speakup doesn't stop reading when the user logs into Gnome. When we type Ctrl+Alt+F1, we get a console screen which is read by speakup. It reads the login prompt, and then all the console text after login, whether as a normal user, or as root. It runs in parallel with Gnome, and never exits until shutdown. Most blind Linux users I know love this behaviour, and will not consider Linux distros that don't support it. This is why web sites like this recoment removing PulseAudio from Ubuntu: http://live.gnome.org/Orca/UbuntuKarmic This is why Ubuntu disables PulseAudio if the user selects an accessible install. I would like to help Ubuntu keep PulseAudio even with an accessible install. Any right solution should require little and probably zero changes to programs like speakup. We should be able to tell the sound system that speakup is allowed to share the sound card with PA. Speakup already has both pulseaudio and alsa drivers, and if we can get either working with PA in parallel, we're in good shape. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, 2010-01-01 at 23:29 -0500, Bill Cox wrote: On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. But for you right === the exact same way it used to work. Hi, Colin. I think it is important to understand where people like Markus come from. I suspect he's completely blind. Sorry, I'm pretty sure from previous mails from Markus that his main issue is a certain hardware his company sells which requires root to be able to access pulseaudio, some TV-sort thingy. He's mentioned this repeatedly in the months I've been on this list. Sorry I can't help more with your issue, I've been reading the conversations about it and think you have a point, but it'll be quite a bit of work to get things working. It may perhaps be better to use alsa with dmix as markus has suggested. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
pe, 2010-01-01 kello 23:13 -0500, Bill Cox kirjoitti: IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. If speakup's model is that the daemon runs forever, without changing the user when sessions are switched, it's in conflict with the normal pulseaudio model, ie. the currently active user owns the sound hardware. If the two programs are to be used simultaneously, one of these two models has to change. Pulseaudio's model can be changed by running it in system wide mode. That's a viable solution, but not ideal for the known reasons. Another approach, which you seem to have started thinking about, is modifying pulseaudio's normal operating model so that it's compatible with speakup. This approach should be used if speakup's current model is correct. Otherwise speakup should be modified. My personal opinion is that speakup's model is not correct, but since I'm not going to do any coding related to this anyway, my opinion is irrelevant. But here's how I see speakup should work, judge for yourself if it makes any sense: At boot --- At boot time there isn't really anybody having a private session; the boot messages are public. Speakup should run as user anybody (that's just a placeholder), and this anybody user has his own pulseaudio daemon running. Then either gdm or a console login manager starts. In my opinion, they should also run as anybody, but there are probably reasons why gdm runs as user gdm. That's why I use anybody just as a placeholder - speakup may also have to use a custom user. At login After logging in, the current session has become private to the logged in user. The pulseaudio daemon that the login manager used releases the sound card, and a new pulseaudio daemon is launched for the user. Now speakup has to start to use the user's pulseaudio. This happens by starting a new speakup daemon instance as part of the user's session setup. Regarding this handover, it may need more or less logic in speakup - I don't know how speakup works. If only one daemon can use /dev/speakup_soft at a time, the previous instance needs to use consolekit to know when to release the access to /dev/speakup_soft and acquire it again when its session becomes active. The pulseaudio daemon of the anybody user stays running, streams to the sound card are just suspended. Speakup should probably detect this and close the stream when the session is deactivated, because when the session is activated again, I suspect you don't want to continue speaking from where you left off. Switching virtual terminals --- Switching virtual terminals works similarly to the login case. The access to the sound card moves from one user to another (might be anybody - in theory it doesn't make any difference whether the terminals have someone actually logged in or if the terminal user is the anybody dummy user). So that's how I see it should work. I'm not very confident when speaking about consolekit and boot/login processes, so I have to hope that the system I described isn't too different from how things work in reality. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Bill Cox wrote: On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering lenn...@poettering.net wrote: We actually cover that inside of gdm, where you can get access to the boot messages. Lennart Speakup doesn't stop reading when the user logs into Gnome. When we type Ctrl+Alt+F1, we get a console screen which is read by speakup. It reads the login prompt, and then all the console text after login, whether as a normal user, or as root. It runs in parallel with Gnome, and never exits until shutdown. Most blind Linux users I know love this behaviour, and will not consider Linux distros that don't support it. I was just thinking, and this idea is perhaps not 100% thought through, but it could be worth considering. We have this hand-over mechanism: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt It looks nice, except for that it lives on the session D-bus. Now assume we move (or copy) it to the system D-bus instead. Then we implement the handover request in speakup, timidity, and other programs not running inside the session context. This seems like a working middle-way between using the user's PulseAudio (which seems difficult, especially when it changes) and the path of uninstalling PulseAudio completely. I'm not a qualified plumber, so I could possibly be missing something obvious here. What do you think? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
