Pulseaudio For Windows
This file is a startup script and is used to configure modules. It is actually parsed and read after the daemon has finished initializing and additional commands can be sent at runtime using pactl(1) or pacmd(1). The startup script can also be provided on the command line by starting PulseAudio in a terminal using pulseaudio -nC. This will make the daemon load the CLI module and will accept the configuration directly from the command line, and output resulting information or error messages on the same terminal. This can be useful when debugging the daemon or just to test various modules before setting them permanently on disk. The manual page is quite self-explanatory, consult pulse-cli-syntax(5) for the details of the syntax.
Pulseaudio For Windows
If the only profile you seem to have is "HiFi", this means that you are using ALSA Use Case Manager profiles instead of pulseaudio profiles. See PulseAudio/Examples#Disabling UCM/"HiFi" for information on how to get back to using pulseaudio profiles.
These two variables are the important ones in order for libpulse clients to locate PulseAudio if you moved its socket to somewhere else. See pulseaudio(1) for more details and other useful environment variables clients will read.
PulseAudio also uses window properties on the root window of the X11 server to help find the daemon. Since environment variables cannot be modified after child processes are started, X11 properties are more flexible because they are more easily changed because they are globally shared. As long as applications receive a DISPLAY= environment variable, it can read the most up-to-date values. X11 properties can be queried using xprop -root, or with pax11publish -d to read pulse-specific properties. pax11publish can also be used to update the properties from environment variables (pax11publish -e, or pax11publish -r to remove them entirely). If possible, it is recommended to let PulseAudio do it by itself using the module-x11-publish module or the start-pulseaudio-x11 command. The following table is there only for completeness, you should not ever need to manually set these variables by hand.
If you have applications that do not support PulseAudio explicitly but rely on ALSA, these applications will try to access the sound card directly via ALSA and will therefore bypass PulseAudio. PulseAudio will thus not have access to the sound card any more. As a result, all applications relying on PulseAudio will not be working any more, leading to this issue. To prevent this, you will need to install the pulseaudio-alsa package. It contains the necessary /etc/alsa/conf.d/99-pulseaudio-default.conf for configuring ALSA to use PulseAudio. Also make sure that /.asoundrc does not exist, as it would override the /etc/asound.conf file.
Here is a two examples where the first one is for ALSA and the other one is for pulseaudio. You can run multiple instances of it. Use the -w option to choose which of the control buttons to bind to the mouse wheel.
One useful tidbit from that page is that load-module module-device-manager should be loaded. This usually happens automatically at login through the script /usr/bin/start-pulseaudio-x11; if you find that the module is not loaded automatically you can consider adding it manually to a configuration file in /etc/pulse/default.pa.d/. See #Switch on connect for possible conflicts with the module-switch-on-connect.
When you first run pulseaudio.exe, you'll see the Windows Firewall Alert popup that asks you if you want to allow other devices for connecting to the server. Since we'll only be using a loopback address (= 127.0.0.1), you should select 'Cancel'; you don't have to allow other devices.
Batch files are updated to address the re-launching problem in some Windows 10 versions. When pulseaudio.exe is launched with '-D' option and stopped using taskkill.exe with '/T' option, pulseaudio.exe might only work for the first instance of X410 and Linux GUI desktop.
The building of this forked version of QEMU has finally achieved me glitchfree audio for a passed through guest using PulseAudio. This means I can play audio in my guest (Windows 10 in this case) but hear the output on my host Linux system and even control the output as if the guest were 'just another application'. Combine this with Looking Glass and you can have windows running, fully 3d accelerated, as literally just a window on your Linux desktop - sound and all (which LG doesn't handle (yet)).
Ever missed the 'Ding' system sound and other standard Windows audio cues? Wine can play them if you tell it where to find PCM .wav files. Because every UNIX is different, Wine can't guess where to find them. See bug 21277 and add a section like this to your `drive_c/windows/win.ini`
First, you will need to download the pre-built binary package from the pulseaudio website, for Windows.Extract the archive, and make sure that you have four different directories: bin, etc, lib and share.Now, edit the file etc/default.pa, to replace the line 61 by:
Hi. This guide will show how to run X11 graphical apps through the WSL environment, WSL stands for Windows Subsystem for Linux and is a sort of reversed wine, it's known for not being able to run X11 apps natively, but there is a really simple way to do that without SSH X11 forwarding, also with pulseaudio support. You'll need:
Regarding the Pulseaudio thing, this is much simpler but similar. You need a pulseaudio daemon running on windows, and then setting the correct Pulseaudio client on WSL to point at 127.0.0.1X11 Setup
Please note that in my .bat script the directories must match with the respective programs, so place all the respective files in a folder like I did, it's better imo.The DISPLAY=:0 parameter is needed even with the .bashrc modified, for some reason the environment variables you modify in the Ubuntu stystem are applied later.Making pulseaudio to work
I have edited my default.pa file to include acl auth-ip-acl=172.16.0.0/12 because WSL2 seems to choose any random address from this range. The only issue with this is that you may get other machines behind your router trying to send pulseaudio sound packets to your computer???
I have been using docker for a while. One thing that I encountered and thought should be interesting is to run a container with a GUI in a windows host, which give me both audio and video of the program. For this test I am using Mozilla Firefox.
Running is simple as starting bin\pulseaudio.exe. You should receive a firewall prompt, allow access. The command prompt will probably show a few warnings about Secure directory creation not supported on Win32. If the process does not exit, then the pulseaudio server is running.
Does anyone know how to change that asynchronous volume levels to synchronous ones as I suspect that to be the cause of the issues?Or can someone still using pulseaudio try to check if the behaviour in alsamixer is the same?
As I have now found out that my rather expensive Bose bluetooth headset works out of the box with Pipewire (it was only usable as headphones with pulseaudio) I have decided to increase the volume on my speakers and stick with pipewire for a bit. Maybe I get used to the behaviour. If not, it is back to pulseaudio.
PulseAudio is enabled by default in openSUSE installations. The daemon is automatically started if an application tries to use pulseaudio. Logging in to KDE or Gnome desktop environments will trigger it to start for example.
If you are having issues with PulseAudio, before reporting them to our Bugzilla, make sure you read this article about the perfect PulseAudio setup. It contains information about making all available sound systems use PulseAudio for the actual sound playing.If on the other hand you wish to disable pulseaudio altogether and fall-back to ALSA for all GNOME based applications, please read section Disabling pulseaudio completely (ALSA fall-back) below.
GNOME installations include all necessary tools and packages by default. In other enviroments pulseaudio is often dragged in due to dependencies but without the tools to control it. Therefore the following packages may need to be manually installed in order to control the pulseaudio daemon:
To make all applications that support alsa but not pulseaudio to play sound viapulseaudio you need to install alsa-plugins-pulse (as well as the 32bit packageif you are on 64bit) and run the following command to make it default:
If on the other hand you wish to disable pulseaudio altogether and fall-back to ALSA for all GNOME based applications, please read section Disabling pulseaudio completely (ALSA fall-back) below.
Certain applications using the OSS audio output, if not correctly configured, could interrupt pulseaudio, such that pulseaudio cannot connect to the output hardware device. This can be disabled by running
Due to dependencies it is often not possible to uninstall pulseaudio completely. To prevent use of pulseaudio nevertheless autostarting the daemon can be prevented by setting autospawn = no in /etc/pulse/client.conf
If the sound still isn't working, or the pulseaudio tools aren't working, try adding your user to the "pulse" and "pulse-access" groups (Yast > User and Group Management > [select user] > Edit > Details > Additional Groups). You'll have to log off and back in for this to take effect.
The alsa plugin that forces applications to use pulseaudio often causes low sound quality in games that use OpenAL for sound output. Up to and including openSUSE 11.1 openal-soft did not support puseaudio natively. To fix sound in games either get rid of pulseaudio or install a backport from Factory
Under openSUSE 11.2, pulseaudio is the audio subsystem of choice for all GNOME based applications. This may cause various coexistence problems, especially in relation to phonon, KDE's sound subsystem that uses ALSA. A very common symptom is that ALSA audio is unable to acquire real-time (or more precisely near-real-time) scheduling, in effect causing delayed and/or clipped sound. Many have found that disabling pulseaudio completely, and thus forcing all GNOME based applications to use ALSA, works much better for them. To accomplish this do the following: