Hello all,
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.
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?
Regards,
Jeremy Banks
On Thu, Aug 17, 2017 at 2:14 PM, Jeremy Banks korethr@gmail.com wrote:
Hello all,
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.
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?
Hi Jeremy,
You're looking for https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winealsa.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/wineandroid.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winecoreaudio.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/wineoss.drv https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/winepulse.drv
note that a lot of the sound code is in mmdevapi: https://source.winehq.org/git/wine.git/tree/HEAD:/dlls/mmdevapi
Andrew Eikum maintains wine's sound infrastructure, he's the guy you want if you have more involved questions.
Good luck!
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
On 08/18/2017 06:55 AM, Andrew Eikum wrote:
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.
Thank you for taking the time to reply. I noticed that a reply was going directly to you, instead of the mailing list, and so hit reply-all. If this was supposed to be an off-list conversation, I apologize, and will direct future replies directly to you.
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.
My use case is recording videos of applications running under Wine, often alongside my running commentary. I initially did use the winepulse driver, as most applications on my computer use PA for general sound (some require it). JACK gets used when I'm wanting to capture audio from my external audio interface, capture multiple sources synchronously so to reduce the amount of manual aligning I have to do when editing and mixing, or during said editing and mixing. As I run both Pulse and Jack, I initially was using the PA -> JACK setup you linked below[1], as it seemed the simplest/easiest solution.
However, I became displeased with that when I discovered that the PA -> JACK bridge was prone to random buffer under/over runs, even with relatively large buffer settings in JACK, and that it would drift out of sync over longer periods of time. I did take a look at the guides you linked at [3], but was left with the impression that doing so would bring even more complexity to the sound setup on my computer, leaving more opportunity for mis-configuration or breakage. It occurred to me that perhaps the Right Thing would be to have Wine talking to JACK natively. When I looked into this and found that Wine did have a JACK driver at one point previously, I thought, "It was done before. How hard could it be?" (Yes, I know that's a dangerous line of thinking :). )
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 understand why you'd be reluctant to add another driver and can sympathize about maintenance burden it would impose. I'd hoped that if I could implement such a driver correctly, it wouldn't impose an undue maintenance burden, and the ability to now talk natively to JACK would be worth it. If you ultimately decide you do not want a JACK driver, I'm tempted to try to implement one anyway, even if it stays my own private patch and never makes it upstream. After looking at the Wine source and the JACK documentation, my curiosity is thoroughly piqued. Even if nothing ever comes of it, odds are I'll learn something, which is seldom a bad thing.
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.
I'll need to research this more to understand the distinction between the two. I know that JACK's API is implemented with callbacks, the main one being a process callback that JACK calls regularly when it wants a program to move data in or out of its buffers.
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.
I noticed those .spec files in the driver sources. I've been trying to put together a mental model of how the drivers in Wine work. I noticed the first function on each line wasn't in the driver source file, but often the 2nd function was (though the ones in the MMDevAPI section do have nigh-identical names). Do I correctly understand that for a line in the .spec file, the first function listed is the function that will be called by MMDevAPi or the application, and the second one is the function that the former will be translated to? Do I correctly understand that the driver files thus contain the translated function calls, plus any additional necessary support functions and data structure needed for getting data to and from the audio system in question?
It occurs to me that since Wine interfaces with Windows applications, I might want to study the documentation for the Windows sound and driver APIs. Is this a correct assumption, or is this not particularly necessary in this case?
[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
Regards, Jeremy
On Fri, Aug 18, 2017 at 02:07:29PM -0600, Jeremy Banks wrote:
I noticed those .spec files in the driver sources. I've been trying to put together a mental model of how the drivers in Wine work. I noticed the first function on each line wasn't in the driver source file, but often the 2nd function was (though the ones in the MMDevAPI section do have nigh-identical names). Do I correctly understand that for a line in the .spec file, the first function listed is the function that will be called by MMDevAPi or the application, and the second one is the function that the former will be translated to? Do I correctly understand that the driver files thus contain the translated function calls, plus any additional necessary support functions and data structure needed for getting data to and from the audio system in question?
Right. Our mmdevapi loads functions from the drivers and calls them to do stuff like determine which driver to use, and to create the IMMDevice and IAudioClient objects.
It occurs to me that since Wine interfaces with Windows applications, I might want to study the documentation for the Windows sound and driver APIs. Is this a correct assumption, or is this not particularly necessary in this case?
Yes, you'll need to understand the APIs that you will be implementing. You don't need to dig into Windows DDK stuff, our drivers operate at a higher level than that. MSDN's mmdevapi docs are pretty good, and you can always reference the other Wine drivers to see how they implement the functions.
Andrew
-
Andrew Eikum -
Austin English -
Jeremy Banks