On Mar 2, 2011 9:32 PM, "Sean McNamara" <<a href="mailto:smcnam@gmail.com">smcnam@gmail.com</a>> wrote: > > On Wed, Mar 2, 2011 at 7:10 PM, Daniel Mack <<a href="mailto:zonque@gmail.com">zonque@gmail.com</a>> wrote: > > > > On Feb 26, 2011 10:00 PM, "Sean McNamara" <<a href="mailto:smcnam@gmail.com">smcnam@gmail.com</a>> wrote: > >> > >> Hi, > >> > >> On Fri, Feb 25, 2011 at 8:28 AM, Maarten Bosmans <<a href="mailto:mkbosmans@gmail.com">mkbosmans@gmail.com</a>> > >> wrote: > >> > As the patches that make it possible to build pulse on win32 should > >> > land in master any moment now, I thought it would be a good time to > >> > make the binaries available for download. > >> > >> This is amazing work! I'm able to play audio from Ubuntu to Win32 over > >> a gigabit ethernet crossover cable (to spare the latency of the > >> router), using Ubuntu 11.04 on the Linux side. No dropouts. I remember > >> doing this a long time ago, but it wasn't nearly as reliable or > >> robust. I've tested several simultaneous streams, with no detectable > >> problems, with Synergy desktop sharing going over the same connection. > > > > Interesting! As I'm currently working on a port to Mac OS X, I'm curious if > > anyone has plans to add a way to redirect audio from native Windows > > applications (ASIO, WDM) to PulseAudio. > > > > I believe it would be mandatory to hack a kernel driver to provide a virtual > > sound card for sinks and sources, just like on OS X. > > Or you can use the fact that module-waveout supports a source, coupled > with a pre-existing Windows device driver that provides a loopback, to > do something like this: But such a driver doesn't exist yet, correct? > Windows audio app (DSound, WinMM, WaveOut, KS, WASAPI-Shared, etc.) > ==> playback of device which supports loopback > > Loopback comes out of kernel as a capture channel ==> captured in PA > server on Windows via module-waveout ==> module-loopback ==> > module-tunnel-sink ==> (network) ==> remote PA server on another > computer. > > Admittedly this is less efficient, but mucking around in the Windows > kernel carries around a lot more baggage than with other kernels. You > have to get it digitally signed if you want to run it on 64-bit OSes. > You have to test it to make sure it works on Windows XP 32-bit, XP > 64-bit, Vista/7 32-bit and Vista/7 64-bit. And 99.9999% of Windows > users have no idea how to build kernel code (nor do they have the > tools to do so), so you have to ship binaries. All in all, a really > ugly task that will be difficult to maintain. I know, Windows is a total disaster, especially in kernel space. We had so much trouble with driver development already, it's unbelievable. However, it would maybe suffice to just support some versions of Windows, and skip the legacy. > If you do decide to go the kernel route, make the actual kernel bits > as lightweight as possible to be resilient against PA protocol changes > and such. Hopefully the kernel bits would be write once, use with any > version of PA for a long time to come. It should be completely independent from PA and just function as a loop-trough virtual device which communicates with the userspace via a simple protocol (for sample rate configuration etc) and exports its audio buffers as shared memory. A userspace part would then be in charge to connect this interface to PulseAudio. I personally have no clue about Windows development, and I would like to keep it that way. Any volounteers with appropriate knowledge? :-) Daniel