Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
Have you tried redirecting the port in SSH? Then you get the native PA with SSH. I am not sure if there is some standard port. Fred Frigerio On Fri, May 20, 2011 at 1:01 PM, Quinn Plattel qie...@gmail.com wrote: Here is pactl stat on the client side: PULSE_LOG=99 pactl stat - Using private memory pool with 1024 slots of size 16,0 KiB each, total size is 16,0 MiB, maximum usable slot size is 16344 Trying to connect to /home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native... connect(): No such file or directory (2) Trying to connect to /var/run/pulse/native... SHM possible: no Protocol version: remote 16, local 16 Negotiated SHM: no Currently in use: 1 blocks containing 16,0 KiB bytes total. Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes total. Sample cache size: 0 B User name: pulse Host Name: Nokia-N900 Server Name: pulseaudio Server Version: 0.9.15 Default Sample Specification: s16le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: sink.music Default Source: source.record Cookie: 26e54bb2 - br, Quinn On Fri, May 20, 2011 at 6:58 PM, Quinn Plattel qie...@gmail.com wrote: Hi, This is interesting: client: ssh -XL 4713:localhost:4713 user@server server: PULSE_LOG=99 pactl stat Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to /home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native... SHM possible: yes Protocol version: remote 16, local 16 Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes total. Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes total. Sample cache size: 0 B User name: quinn Host Name: server Server Name: pulseaudio Server Version: 0.9.21-63-gd3efa-dirty Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: auto_null Default Source: auto_null.monitor Cookie: 6ccbf517 server: export PULSE_SERVER=localhost:4713 server: PULSE_LOG=99 pactl stat --- Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to localhost:4713... connect(): Connection refused Connection failure: Connection refused --- Ideas? Quinn On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie gm...@colin.guthr.iewrote: Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from xprop -root | grep PULSE. Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) 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
Re: [pulseaudio-discuss] system-wide daemon
They way I worked out a similar situation (I am doing an ssh from the box into the box and sometimes from a different box into it) was to setup the PA of the user I ssh as and it IS a user that I would never login directly as to use PA over the network. So as long as someone is logged in then it's PA works. You could have a couple of different configurations sitting around and do some shell trickery and start different configurations depending on the environment. Does PA support conditional config files? Maybe it can be all kept in the PA file and just set an environment variable. Fred F On Tue, Feb 9, 2010 at 11:59 AM, Markus Rechberger mrechber...@gmail.comwrote: On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. The only point is that this behavior should be considered to be fixed up again in future. I would not wonder if a remote login in windows as a different permitted user would provide audio support. I do agree that when the user behind the PC is switched that those audio instances should be exclusive. But remote terminals are a different topic and should be handled different. the problem I see with that design is that as soon as the user logs out the PA process might vanish again so you are really stuck with the system daemon if you want to get multiuser support. although another possibility might that other PA daemons connect to the first PA instance and just pass through the first instance might do some user accounting and only shut down when all other PA instances are gone but in that case the system wide mode seems to be more elegant again... Markus ___ 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] [0.9.17]Missing audio-headset-bluetooth icon terminates pavucontrol
A distro like Gentoo would help you in this case if you want to be selective about piece meal upgrades but still there is some pain if mixing bleeding edge libraries with more stable software. I tried to move on to this PA and the dependencies were difficult to deal with so I postponed testing of it until later. :) Fred Frigerio On Fri, Sep 18, 2009 at 2:50 PM, Lennart Poettering lenn...@poettering.netwrote: On Fri, 18.09.09 14:28, Peter Hurley (phur...@charter.net) wrote: Hi Lennart, Heya, Turns out this is more easily said than done. The new libcanberra dependency is a fair bit of work to resolve. They invented distributions so that you don't have deal with dependencies. Also, I'm not clear why the udev detection code isn't considered experimental in pulseaudio. Deprecating module-detect already seems a bit hasty. module-udev-detect depends on a version of udev that's barely 3 months old. Additionally, even with the revised udev, some fairly graceless means of making that work are employed. PA makes use of features from the latest kernel, latest udev, latest gcc, latest glibc. I cannot see what could be wrong with that. PA is after all a low-level component of today's Linux system, so either upgrade it with the rest of the OS, or don't at all. Based on the shortcomings of udev exposed by pulseaudio's usage, Shortcomings? perhaps pushing for a more appropriate udev messaging sequence/device enumeration/driver status makes sense? I don't see why. I have been working with upstream udev to integrate the necessary work in udev upstream, and hence I depend on a recent udev version. What you are asking me instread is adding all kinds of wrkarounds to PA itself to keep compat with old udev versions? That would be simply the wrong way, problems should be fixed where they are, not worked around. 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 mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
