[pulseaudio-discuss] Windows binaries

[Sean McNamara]

On Wed, Mar 2, 2011 at 7:58 PM, Daniel Mack <zonque at gmail.com> wrote:
>
> On Mar 2, 2011 9:32 PM, "Sean McNamara" <smcnam at gmail.com> wrote:
>>
>> On Wed, Mar 2, 2011 at 7:10 PM, Daniel Mack <zonque at gmail.com> wrote:
>> >
>> > On Feb 26, 2011 10:00 PM, "Sean McNamara" <smcnam at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Feb 25, 2011 at 8:28 AM, Maarten Bosmans <mkbosmans at gmail.com>
>> >> 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?

Such a driver does exist. First of all, if you have the right sound
card + platform combination, you get a loopback capture channel "for
free" as part of installing your sound card's drivers -- no further
effort needed. This is soundcard-dependent. I hear that Creative
SoundBlaster based cards (both the really old ones, and the current
ones) have the best chance of providing this.

In case you don't have that, you can use the proprietary, commercial
software "Virtual Audio Cable". It is digitally signed and works on
all versions of Windows starting with 32-bit XP, all the way up to
64-bit Windows 7. The cost is typical for proprietary Windows
software, at $50 USD -- so not too cheap but not too expensive. Since
you're already running Windows (the generic "you", as in, any
interested user), you should already be used to paying for proprietary
software, and so, this should be no problem. :)

A FOSS version of Virtual Audio Cable would be welcome, but I don't
think you would get that digitally signed by Microsoft WHQL. I heard a
rumor (possibly false) that lack of publicly available source code is
a criterion for WHQL acceptance, for "security" [through obscurity?]
reasons. It has to be signed for the driver to load at all on 64-bit
Vista / 7, unless you boot your system into test mode, which I can't
recommend for security and stability reasons. Test mode is also either
tedious (you have to do it every time you boot) or risky (install
untrusted third-party software that automates booting from test mode
for you). And IMHO, 64-bit Vista/7 are the flagship OS products of
Microsoft right now; 32-bit is basically deprecated.

>
>> 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.

In that case, you could probably write one driver for Vista and
Windows 7, 32-bit and 64-bit, without major code changes between 32/64
and Vista/7. The audio driver stuff changed sufficiently with Vista
that a separate driver is needed to support XP in any fashion.
Throwing out XP would certainly simplify things, but you still have a
big task ahead :)

>
>> 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.

Yeah, this is what Virtual Audio Cable does. If you want to go this
route with the module-loopback method like I suggested, keep in mind
that the audio is copied *a lot* between kernel/user, local PA and
remote PA, and that we could save quite a few copies if we could
bypass the Windows Audio subsystem when bringing the audio back around
through the loopback. Then we could implement something in PA like
module-ourdriver-sink, and the data path would be something like:

Windows Audio app (WinMM, DSound, WASAPI, etc) ==> Windows libs and
API ==> kernel ==> our WDM driver ==> back to userspace ==> pulseaudio
(shared mem or so). Better yet, integrate the "back to userspace" part
with client.conf and libpulse, so you can have libpulse pipe the sound
directly over the network rather than using
module-tunnel-{source,sink}. This would then make the audio path
basically equivalent to the way we do it with ALSA. Indeed, if you
wanted to play back the sound locally, it would just go through
libpulse to the local daemon over native protocol, and the local
daemon would playback to a "real" Windows Audio device such as your
soundcard. This would be a way to get all sounds on your Windows
computer routed through PulseAudio, with much less copying and
buffering than the Virtual Audio Cable :)

-Sean

>
> 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
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
>