JACK driver for WINE

[Andrew Eikum]

On Thu, Aug 17, 2017 at 01:14:00PM -0600, Jeremy Banks wrote:
> I am wanting to output the audio from various applications run in WINE to
> the JACK server on my computer. I would prefer that WINE do this natively
> instead of routing across various wrapper setups with ALSA or PulseAudio. I
> have looked on the WINE wiki page for sound[1]  and see that there was a
> JACK driver at one point, but it was removed when the driver architecture
> was changed.
> 

Hey Jeremy, thanks for your interest! Like Austin said, I do most of
the audio stuff in Wine these days, so you'll probably be working
mostly with me.

First, I'd request that you try out the alternatives to implementing a
driver. I don't know what your requirements are, but there are
existing solutions for running PulseAudio on top of JACK.  I'm not
super familiar with JACK, but I think you'll want to follow the
"Redirecting PulseAudio to JACK" section here[1], then make sure Wine
is using the winepulse driver.

If that doesn't meet your requirements, you could also try redirecting
winealsa to JACK, see[2,3]. This may have lower latency than running
PA.

The reason we resist adding new drivers is it adds a lot of work for
the maintainers (i.e., me). I test each significant change to any part
of our audio code on all four of our existing drivers (ALSA, OSS,
PulseAudio, and macOS's CoreAudio), both by running the Wine unit
tests and by testing all of the many audio applications I have that
use the relevant APIs. On top of the testing itself, that means I have
to understand how to run and maintain all four of those audio systems
on my hardware.  Further, any bug fixed or new feature added to one
driver has to be understood and replicated in all other drivers, if
applicable.

So you can see why I'd request you try existing solutions before
jumping straight to a new audio driver. If you can convince me that
existing solutions don't work for your requirements, then we can talk
about adding a new driver to Wine. I'd at least like to be convinced
that you've already tried alternatives and understand why they are
unacceptable for your usecase.

> I am interested in trying to implement a driver to get WINE talking to JACK
> natively. The wiki says to ask on the mailing list before starting such a
> project, and so here I am. I have downloaded a local copy of the source repo
> and have started browsing through its contents. Being unfamiliar with the
> WINE codebase, which portions of the source should I start studying first? I
> am interested in studying the drivers for ALSA, OSS, and Pulse for
> comparison; do those live in a particular place in the source tree? I'm
> presently looking on the Wiki for other helpful information, but is there
> some particular documentation I should be studying for this endeavor?
> 

Once you get over that hurdle, you'll need to implement a winejack.drv
similar to winealsa, winepulse, winecoreaudio, or wineoss. You'll want
to copy whichever is closest to JACK's API and then modify it to use
JACK. winealsa and wineoss operate in push mode (we maintain our own
timers to keep the audio buffer full). winepulse and winecoreaudio are
in pull mode (the audio system asks us to provide it with data). I
don't recall which type of API JACK is.

At a very high level, you'll need to implement all of the functions in
the .spec file. You can look into the existing drivers to understand
what those APIs do. The audio drivers export a few COM interfaces,
which are used directly by applications or by dsound, winmm, and some
other modules. The really important interfaces are IAudioClient,
IAudioRenderClient, IAudioCaptureClient, and IAudioClock, and there
are a few lesser-used interfaces besides.

Once you've implemented those interfaces, they'll need to pass the
tests mentioned on the wiki page.

[1] https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_PulseOnJack

[2] https://wiki.winehq.org/Sound#What_about_JACK.3F

[3] http://jackaudio.org/faq/routing_alsa.html

Andrew