i want to stream sound from a windows (pulseaudio server) to a windows (pulseaudio client) but i can't hear sound from windows (pulseaudio server)

following steps were done:

• running pulseaudio on windows (server ip 192.168.0.11) and windows (client ip 192.168.0.22)
• on windows client executing pactl.exe load-module module-tunnel-source-new server=192.168.0.11

result:

• the windows server shows a connection of the windows client, but no sound can be heared on the windows client.

: [(null)] ../../src/pulseaudio/src/pulsecore/client.c: Created 0 "Native client (TCP/IP client from 192.168.0.22:51060)"
: [(null)] ../../src/pulseaudio/src/pulsecore/protocol-native.c: Client authenticated anonymously.

is it possible that the windows server have to redirect somehow the audio signal to the soundcard driver? is this possible at all to get a remote stream from windows to windows? any advice?

I am attempting to setup PulseAudio to be a sink for my OpenHAB home automation server. (https://www.openhab.org/addons/bindings/pulseaudio/) but I'm running into a lot of issues. Firstly the windows build from the PulseAudio website will connect beautifully just by adding load-module module-cli-protocol-tcp to the default.pa and passing that in as a launch command but the audio received was being played way to fast so I tried to find a support page and I ended up on the Element chat room where no one knows anything about the windows builds haha but one guy found your site and I decided to start trying it instead but now I get a whole new set of issues.

If I enable the use default.pa or use a default.pa as a launch command I get a too many commands error and the server just wont start. I can not see any rhyme or reason to this either. If I disable it again and simply try to edit the system.pa I can get it workingish I'll post a different issue for those problems.

I'm going to look into creating a WASAPI module to allow for:

• 1:1 output devices
• 1:1 input devices
• Loopback of system audio
• Optional linkage of device volume with PA volume
• Custom application labels in the mixer
• Latency options
• TODO

I've never worked with WASAPI nor created a PA module from scratch, so this might take some time to figure out.

Hello,

First of all, thank you for building this. It's really great! The old "official" win32 port of pulse audio was really showing it's age.

Also, thank you for distributing the binaries so that people don't have to compile this themselves!

I was wondering if you have been able to get these to compile as a 64 bit application. Would it be possible for you to distribute the 64 bit version alongside the 32 bit one?

If it's too much trouble, do you think you could provide some guidance on how to compile this targeted for 64-bit windows?

Thank you again,
Chris

• Figure out how the event log API works.
• Decide whether to have PA itself create the event source if it doesn't exist or whether to leave this to the installer (I think logs will go into Application if the event source isn't found).
  • Allow all users to write to the event log when creating the event source.
• Decide whether to make PA use the event log by default (it currently does this for systemd-journald).
• Integrate it with pulseaudio/src/pulsecore/log.c.
• Upstream the patch?

Dear Patrick,
I am filing this issue after exhausting the following paths to solve my problem:

• Changing variables one by one and testing the results,
• Following 2 different threads on the web claiming that sound under WSL works,
• WSL refers to wWSL2 witth updated Ubuntu 21.04,
• Reinstalling Pulseaudio from scratch,

If you could help out with a working configuration if you happen to have one or clarify a bit more the following:
What configuration directory is used by the windows service? There are 3 possible places or more, where configuration files can be or are placed:

• Program files folder with /ebc/...,
• Program data folder with: pulseaudio mentioned in hte log output,
• Administrator home folder .config/pulse/,

Which files should be modified to enable TCP protocol and allow connections from WSL. The WSL virtual machine is assigned a local network address from the pool in 172.16.0.0/12 - I found this vale in a few threads on the web.

Last but not least. Any hints about proper configuration on the WSL Linux side besides setting the $PULSE_SERVER environment variable to the assigned IpP address?

Thank you in advance for your time and help...
Pawel

Hi ,

i got pipewire-pulse running on debian bookworm , it should play audio.

i got your code running and connection is successful on Win11, but how can i select the audio source to be played on the remote server ?

regards and thanks for your effort,
Simon

This would solve issues with overly broad permissions, volume control acting oddly, and file permissions.

• Connect via a unix socket in AppData (or is there a better place for this?).
• Figure out startup
  • Maybe per-user instances on Windows 10 (https://helgeklein.com/blog/2021/01/per-user-services-in-windows-info-and-configuration/).
• Integrate with the installer.
• TODO

Depends on #5

• Feature parity with the existing installer.
• Eliminate the need for install-time patching of configuration files (done in 58f5e6d).
• Ensure config files in *.{pa,conf}.d are preserved between updates/reinstalls.
• Remove pasvcfw?

• Ensure Unix socket creation works.
• Figure out a way to patch the system-wide local state dir to use ProgramData.
• Test the user-specific state dir.
• Fix auto-detection.
• Add options to the installer?

Split from #2

With pulseaudio running on a windows 10 machine using module-cli-protocol-tcp to send TTS messages from openhab using (https://www.openhab.org/addons/bindings/pulseaudio/) I am receiving the audio clips at crazy play back speeds. Even reducing the playback to 1/4 speed is not understandable. While it may be easy to blame openhab the same messages play at a standard speed when sent to another speaker source and a wav played locally via pactl appears to play normally so presumably it has the most to do with the module-cli-protocol-tcp but I have also posted an issue with the bindings github (openhab/openhab-addons#11662). At the moment I can not find a way to verify who's causing the issue as I can't seem to figure out how to send a test sound to cli using telnet and putty.

I am using PulseAudio to setup a sink source for an OpenHAB instance using this to connect (https://www.openhab.org/addons/bindings/pulseaudio/) and I've notice some oddities. By default PulseAudio should be using 4712 for module-cli-protocol-tcp and 4713 for module-native-protocol-tcp but your version appears to use 4712 for module-native-protocol-tcp and so when you enable module-cli-protocol-tcp with module-native-protocol-tcp it kind of bumps module-cli-protocol-tcp to 4713.

I know this because openhab can only connect using module-cli-protocol-tcp. When both module-cli-protocol-tcp and module-native-protocol-tcp are loaded openhab can only see the server on 4713. If I disable module-native-protocol-tcp I can only connect on 4712 and if I use the old windows version from the pulseaudio site it also connects on 4712. Unfortunately with module-native-protocol-tcp disabled I can't do any pactl commands as it uses that protocol and a lot of that openhab bindings code is hard coded to 4712 so I can see the server but I can't connect to a sink.

Now I have post an issue about the hardcoding to them (openhab/openhab-addons#11661) but unfortunately that doesn't mean there isn't an issue here to. The problem with this comes in the fact that if you try to define load-module module-native-protocol-tcp port=4712 which should fix it and allow me to have both running using the port argument, PulseAudios Server starts to act strange. Things will connect right quick like it is running fine but a pactl -s 127.0.0.1 list will time out and trying to send audio also appears to time out and neither show in the log. Now I tried to look through the win32 code to see what might be causing it but I can't find anything that should cause that behavior or the port change.

• Move service logic directly into pulseaudio/src/daemon/main.c.
• Decide whether to always attempt to create a service, or whether to put it behind a flag.
• Maybe make PulseAudio see the system service as a system instance rather than a user instance. This would also eliminate the need for messing with config paths when creating the service.
  • Figure out the implications of PA's system flag.
• Decide whether to keep the pasvc command.
• Upstream the patch?