-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PulseAudio doesn't work. #486
Comments
This looks related to #237 in the sense that we are not exposing hardware / drivers through WSL. For this, your best bet is to submit a feature request over on our User Voice Page to help us prioritize future releases. |
It is possible to run PulseAudio over TCP, and there is a native Windows port of the PulseAudio server. However, it seems to want to use a SOCK_DGRAM, which doesn't seem to be supported yet. |
Specifically, the failure is as follows:
On real-Ubuntu, the equivalent My understanding is that Pulse uses local sockets for some sort of internal communication. I think, though I'm not sure, that it starts a helper process to handle communication with the remote server, and it handles communication with that process using this socket pair. |
@aseering So I commented on the other thread with some info, and I also found some other stuff: By default, Pulse loads a module called module-native-protocol-unix, and another module called module-native-protocol-tcp can also be enabled. I wonder if you can start pulse with a config that does not enable module-native-protocol-unix at all, then disable all of the non-native modules that listen over datagram-mode unix sockets. It looks like this might be possible, and if it is, Pulse won't try opening that unix socket and should startup fine, I think. As I mentioned in the other thread though, I won't be able to test it this weekend bc hardware problems, but maybe this could help. Here is a list of the modules that have both TCP and unix variants: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index22h3 Maybe if you turn off all of the unix modules and replace them with TCP variants, you can start the pulse server. |
Aren't those modules loaded by the server? The server in this model runs under Windows. This strace is from the client. |
@aseering Nope, it runs those as well as the sink modules on the linux side. That's why I mentioned "trunking" from one to the other. Basically, there are two modes, a "bridging mode" that basically pipes all of the channels in multiplex to the remote server (Windows), to allow mixing of channels, etc on the remote machine, and a "flattened" version where the mixing and filtering and stuff are done on the "linux side" and then the output of the mix is piped to the Windows "client". However, both modes of operation do have to use some kind of socket or port. For example, OSS sound (for which pulse has a sink) uses unix ports, so Pulse's OSS sink module will trick all OSS applications into piping their output to a unix socket opened by Pulse. Similarly, you can have a pulse module for Alsa, etc. In addition to those sink modules, pulse has a "pulse sink" for pulse-aware programs. This "pulse sink" module is "pulse-native-protocol-*". Remember, pulse needs a some kind of socket that the linux programs have to talk to on the linux side. Then Pulse can either bundle them up and pipe a multiplexed stream to another Pulse server for processing or process them and then pipe a single processed stream to the other pulse server. I believe (and I can't check bc my pc broke) that if you disable linux-side pulse from using any modules that use unix sockets, it should launch fine. Basically, this hypothesized fix should work similar to how the dbus fix works, I think. |
That all sounds very complicated... I just have every Pulse application individually opening a TCP socket to the Windows daemon. |
@aseering Oh, seems like that should work. You are saying that you aren't running pulse on the Linux side, but you also told me that it crashes, which seems like you are running it. Or are you saying you used a workaround to get it to work? (Also, fwiw, the benefit of running Pulse as a remote server and connecting it to another instance of pulse on your local machine is that not every Linux application with sound will output audio to pulse over tcp, mostly older programs or games. That's why pulse in Linux has all of those sink modules). |
@fpqc -- oh, sorry, terminology confusion. Let me define some more-specific terms:
By editing /etc/pulse/client.conf in WSL, I have configured Linux binary applications that link libpulse (tested with both I have also configured pulseaudio.exe to listen on TCP localhost. I have not configured Linux pulseaudio, nor attempted to start it. I am observing a failure (not a crash, simply an error as well as no audio) coming from libpulse inside WSL, when I run applications that link libpulse. If I modify the IP addresses used in this setup and use libpulse on a real Linux system (but still pulseaudio.exe on Windows), I do not see this failure, and I do hear audio, so the Windows side of the setup seems to be working properly. When I strace the application that's calling into the relevant libpulse code, I observe that the first syscall that obviously differs between the working Linux execution and the failing WSL execution is I was looking around on the Internet and I thought I read somewhere (unfortunately I don't remember the source; it was unofficial) that libpulse actually tries to internally start is own mini Linux pulseaudio subsystem, to handle communication with the actual target pulseaudio. My suspicion, though I didn't read enough code to prove it, was that this socket was for communicating between the client application and that application's own custom pulseaudio instance. |
I wonder, if you do run the pulse daemon in unix socket mode, do the applications still start a mini pulse instance and create its socketpair in order to connect to the daemon. How about if you run the pulse daemon in tcp mode? (on a single linux system, no remote machine). |
Actually, @aseering, could it just be something as simple as this https://wiki.archlinux.org/index.php/PulseAudio/Examples#Disabling_automatic_spawning_of_PulseAudio_server https://wiki.archlinux.org/index.php/PulseAudio/Examples#Disabling_pulseaudio_daemon_altogether Namely that it's starting the daemon and choking? |
@fpqc -- good point re: disabling automatic spawning. Unfortunately, I tried it and it doesn't seem to help... I tried running a local pulse daemon (which started after I disabled a bunch of plugins for things like bluetooth and hardware autodiscovery); that actually failed differently. In libpulse, as run from
|
I got Interestingly, I didn't need to patch the source, just judiciously disable some stuff with On the WSL (ie, client) side, all you need is:
You can also edit That's the good news. The bad news is that mplayer and minimodem don't work because:
Firefox and VLC also don't make noise yet, but I haven't tracked why. They do open the socket to the win32 server before choking, though. |
@therealkenc -- ooh, that's really interesting. Good to know. What ABI-compatibility guarantees does pulseaudio provide? Ubuntu 14.04's packages are all built against pulseaudio 4.0. |
@aseering Hahahahahaha, Compatibility guarantees with pulse. I'm an Arch user from time to time, pulse just breaks for no reason and the only answer is to reinstall the system or track down some strange config file you need to destroy. Any time you do an Arch update, it's a potential adventure! |
@aseering - the Pulse client API is stable to a first order, FWIW. That is, the same Firefox binary will make the same sounds on Trusty, Wily, Xenial, and Yakkety. It looks like Pulse keeps bumping major numbers because the server plugin API is relatively unstable. |
I got back to the futex problem. Amusingly, the patch is utterly trivial. Just add
VLC works out of the box with the replacement shared library installed. I confess I don't know how to get minimodem to make screeching noises but it probably works too. Youtube videos on Firefox stream with audio completely in sync. |
@therealkenc Wow, that's fantastic! How is performance? Also, some insight on how you tracked that down if you don't mind!? |
Performance (if that is the word) is great. The amount of cpu horsepower and memory bandwidth required to push a couple of audio channels over localhost is dwarfed by what it takes to decode an H.264 video stream coming down from GoogleCorp. That is, the difference between having audio and not audio isn't measurable. I pessimistically just assumed there was going to be sync problems (which is an A/V problem on a good day), because "buffering", but apparently not. Tracking this one down was pretty straightforward because the failing syscall is |
@therealkenc -- I played around some more with your instructions. From your list of packages, it sounds like you're using an upgraded xenial system? I got your instructions to work on trusty by playing around with the set of installed build-deps and the set of enabled/disabled flags for pulseaudio's ./configure script. So far, works great for me! I haven't exercised it very much, though. |
If anyone wants to try this without rebuilding pulseaudio: I've taken yakkety's pulseaudio package (which is based on v9) and backported it to trusty, using a modification of @therealkenc 's build instructions plus some playing around to get the packaging right (since a bunch of different modules are being built / not being built). I posted that package to a PPA: https://launchpad.net/~aseering/+archive/ubuntu/wsl-pulseaudio If you:
then pulseaudio-based applications should play sound for you. |
I did this on Trusty FWIW, but I put the dependency list together after the fact so if something was missing that isn't too surprising. 👍 on the PPA. People who are used to adding For people setting up the Win32 side, the tl;dr is you need the following in your
|
Interesting; it was partly the packages that were listed as well as packages that were omitted. For example, trusty's official repo doesn't have a package for gcc 6. There were a couple others as well; I forget the list, you can check out the Build-Deps in the PPA if you're curious. For I also found that the Windows server was automatically exiting after some period of time (order of a minute?) of being idle, but only after I stopped playing music (not before I started). I think there's a setting for that too? But I forget which setting offhand. |
The gcc-6 thing was an omission on my part; apologies for that. I updated the instructions yesterday, probably just after you read them. PA seems to prefer a C11 compiler (Xenial doesn't have gcc-6 either).
Yes omitting
I don't have a microphone so I also needed the following in
That's probably enough in a nutshell for your HOWTO. |
Also heads up that I get a 404 on Trusty when trying to
There is probably also a way to make your PPA Unubtu release agnostic for the Xenial people, like ubuntu- |
"C11 compiler" -- thanks for the update! PPA packages are built in Launchpad's build environment, which AFAIK can only install official Ubuntu packages, so I had to play around a little more to get things working. Also, thanks for the additional config directives; they'll be useful to have. For the PPA, sorry for the confusion -- the URL above is for the pretty webpage, not the apt repo. For the actual repo,
|
I have same problem with running pulseaudio, I described it on reddit: |
Use ppa linked above but it may not work since there is now a new update. Hence the FYI to @therealkenc |
the latest update doesn't work with the PPA, however someone in that reddit thread has said that one of the devs is working to implement whatever missing function. so hopefully that means there won't be a need of waiting for patches. |
And Pulseaudio now works beautifully on build 17627. 🎉 |
This one is slightly awkward. "Audio" categorically does not work in WSL, because there are no OSS/ALSA/FFADO drivers in WSL. But there are no remaining blockers on the PulseAudio client ( |
Did the fix seen in the 17627 insider build get pushed out in the big April W10/WSL public update? |
@cuprousoxide - In general, the fixes in 17627 will not make it to April W10. |
Hi @tara-raj, is there any other reference ticket/issue where we can see progress of this issue? |
Hi, I got this to work with great thanks to everyone in this thread. I am now able to use paplay while being ssh-d into a remote machine (CentOS 7) and hear sounds on my local machine (Windows 7). However, I wanted to use padsp and that does not seem to work. I am running my application like so while being ssh-d to my remote machine: /usr/bin/padsp-32 application_name And I don't hear any sounds on my local machine. Could this be because the pulseaudio for Windows does not have padsp? I know that padsp forwards sound to the PulseServer which I know to be working fine because of paplay. But, does it attempt to use something like a "padsp.exe" on the local machine and doesn't find it? Or do I need to do something else? Like load a particular module into my pulse audio on the Windows side? @therealkenc, do you have any ideas? |
|
Could you take a look with |
Makes noise here.
|
So the pulse audio server on my windows stops after a few seconds of inactivity, this is even though I am running it with the --daemonize flag. Any ideas? @therealkenc |
@therealkenc I am getting the following error while attempting to start pulseaudio.exe on my Windows:
And I get a Do you have any idea how to go about fixing this? |
Not really. Suggestion would be to not run |
I fixed it by simply restarting my machine. What's the best way to keep pulseaudio running? It keeps stopping for me. @therealkenc |
For anyone interested, the above Ubuntu xenial repo is working with WSL Debian testing as well. |
I am trying to use minimodem on the bash shell, and it gives me an error:
E: Cannot create PulseAudio stream: Connection refused.
I am not sure how to fix it... Help please?
The text was updated successfully, but these errors were encountered: