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_Puls...
[2] https://wiki.winehq.org/Sound#What_about_JACK.3F
[3] http://jackaudio.org/faq/routing_alsa.html
Andrew