Hello, I think this is related. 

It happens on FC12 upgraded from FC11 via network. AMD Phenom 9500 64bit system.


In essence sound should be played on speakers if user has logged in remotely. Here is what happens:
1) When I log on remotely (from another computer going via no-ip) using my account (me currently logged in via gnome) - the sound plays even if I am playing rhythmbox at the time.
2) When I log on remotely using test account - the sound does play - but only if rhythmbox is paused. I can even start playing sound on console, then pause rhythmbox and after a short while the sound would come through


Here is what happens in /var/log/messages
a) when I (on xwindows - gnome) try to play a paused rhythmbox when the remote test user has already started playing a sound:
pulseaudio[3672]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
shortly after that sound is finished rhythmbox resumes playing
b) when I try to play a sound as a remote user when rhythmbox is playing
pulseaudio[4003]: main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.Spawn.ExecFailed: /bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.
if I pause rhythmbox some 8 seconds later the sound played by the remote user comes through speakers

In other two cases there are no errors in /var/log/messages:
- when I play sound over rhythmbox logged in remotely as myself
- when playback starts for the remote test user - if rhythmbox is not playing

And as one would expect same as for rhythmbox goes also for totem.

I'd appreciate any ideas how the other user account could play sound when the logged on user is using rhythmbox. Should I fill this as a bug or is it the same as this one?

Thanks, Roberts

When logged in via SSH you have no access to keyboard, mouse, screen or the sound card of the system. That is expected behaviour. If this wasn't that way you could eavesdrop into what the user types, looks at, talks and hears. Would be a big security hole.

I've been busy over xmas, so missed the above comment, by Poettering.

What total bollocks, I have access to anything that has an i/o  driver to access it, I can't depress keys on the keyboard but I can switch indicator lights on/off, I can certainly access the screen with ssh -f user DISPLAY=:0.0 smplayer movie.avi (and if an .Xauthority file is required just use ssh -fX)

Are you a fucking n00b?

(In reply to comment #3)
> I've been busy over xmas, so missed the above comment, by Poettering.
> 
> What total bollocks, I have access to anything that has an i/o  driver to
> access it, I can't depress keys on the keyboard but I can switch indicator
> lights on/off, I can certainly access the screen with ssh -f user
> DISPLAY=:0.0 smplayer movie.avi (and if an .Xauthority file is required just
> use ssh -fX)

If you do this and you are running PA on that session the X11 display belongs to, audio will automatically be directed to it because the X11 root window will carry the contact info of the PA server. However you will only hear it as long as the display is activated. i.e. meaning, when you can see the session on the screen you will also hear the audio.

> Are you a fucking n00b?    

Yes, I am. I have no idea what I am doing, and thank you very much for telling me that, because otherwise I would never have found out. Also, using those words on me makes me work particularly well and makes me react to your requests especially promptly and friendly.

Yeah I probably should have added a smiley, it was an attempt at ironical humour, considering the (often underserved) abuse you get.

However, your reply is still not helpful because prior to F12 I could always play audio files remotely via ssh, with or without an X server. So something's changed.

er, I mean undeserved, not "underserved" (which might be misinterpreted ;) )

(In reply to comment #5)
> Yeah I probably should have added a smiley, it was an attempt at ironical
> humour, considering the (often underserved) abuse you get.

Ah, right. Ironical. 

I must disappoint you. I don't get much abuse, neither deserved nor undeserved. You are by all means an exception in politeness.

> However, your reply is still not helpful because prior to F12 I could always
> play audio files remotely via ssh, with or without an X server. So something's
> changed.    

Right. You still can. And the console swiching based audio device ACLs we introduced In F9 or so. There's nothing new here.

Ok, I tested with a fully updated F12 and it now works ok.

But it WASABUG when I posted a month ok.

So we'll put this one down to "fixed by magic"

Thank you for looking into this. Unfortunately I do not know how to use console switching audio device ACLS. Could you please give me a brief rundown how to allow another user to play audio when I am logged in and using an audio app (rhythmbox in this case).

Despite latest updates the problem still remains exactly the same as I have described above - if I log in as remote user I am able to play a sound if rhytmbox is _not_ running for the logged in user, however no sound reaches speakers when rhytmbox is on for the main logged on user. 

Error in /var/log/messages again is as described above:
Jan 14 11:02:04 robbie pulseaudio[16519]: main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.Spawn.ExecFailed: /bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.

I promise to make a detailed tutorial out of this when I get it to work, but I do need your help for this, as this is a bit beyond my understanding. I am only a linux enthusiast with some perl, php background.

I imagine the PA server might have some settings whereby the remote user would be allowed some access to the audio device whilst it is in use, but I have no clue how that may be achieved.

Many thanks in advance.

Yes I was wrong, the problem does remain. The test I ran above which worked was from a fresh fedora 12 install to a Fedora 12 install that had been UPDATED (via the install dvd) from Fedora 11.

If I do it the other way round, then the situation is exactly the same as reported in post #1, bluetooth, dbus errros and X11 errors.

Both Fedora 12 machines are fully updated from the standard repos.

If the security model for pulseaudio has changed since Fedora 11 then it should be documented. This works fine in F11 (and earlier versions).

If the feature is intended to prevent remote users playing audio in F12 then there is something wrong with the update install from DVD, since it allows user 'test' to play audio while someone else is logged in on my updated F12.

and just to clarify, you can play audio via ssh as user root or the currently logged in user, but I guess that's the expected behaviour.

Do enlighten us on ACLs and how they work in this context, Fedora security model is so convoluted now that even the devs don't seem to know how it works (cf Hughsie's policykit debacle with allowing users to install local packages)

Oh yes, let me google that for you.

Even the mighty google can't locate an understandable document.

Still, since I seem to have sneakily bypassed any intended security feature by doing an upgrade rather than a fresh install of F12, I'm not really bothered.

I was reporting on behalf of a forum poster who uses ssh + aplay to signal his brother upstairs, since Fedora 12 he's been having to actually communicate with him IRL via his own human voice.

So perhaps the unintended result is good after all.

Thanks guys for the interesting discussion. I wish my situation was same with brother upstairs, but in my case he is actually in a different country about 2500 km away. 

My googling did not lead to results that I could understand. I would really appreciate if some advice could be give as to why the described behaviour happens and whether I could rectify the situation - at least for the specified account. Would adding my brother's account to pulse or pulse-access groups change the situation in any way?

Thanks