Hi,
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
Thanks.
Eric Pouech is the original author, so if he still hangs around here he would be your best bet.
On 9/8/06, Aaron Slunt tonglebeak@gmail.com wrote:
Hi,
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
Thanks.
On 9/8/06, Tom Spear speeddymon@gmail.com wrote:
Eric Pouech is the original author, so if he still hangs around here he would be your best bet.
Robert Reif has done extensive work on dsound as well.
On 9/8/06, Aaron Slunt < tonglebeak@gmail.com> wrote:
Hi,
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
Thanks.
Tom Spear wrote:
Eric Pouech is the original author, so if he still hangs around here he would be your best bet.
for the sake of record, I'm not the alsa driver author (at least not the current 0.9x / 1.y) A+
Aaron Slunt wrote:
Hi,
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
the rewrite we're talking about is dealing with putting most of the drivers in a single DLL, and abstracting a bit the implementation of the interface but it will not modify the core of the ALSA implementation, nor any issues related with current code
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
if it doesn't work in a satisfactory manner for you, then you should fix it A+
On Fri, Sep 08, 2006 at 04:43:18PM -0400, Aaron Slunt wrote:
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
The alsa specific problems should be fixeable without touching the rest of winmm or dsound. They each have problems, but not directly related ones. In fact one of those bugs is realy grave.
See bug #4093 : deadlock in alsa driver: CriticalSection WINEALSA_mmap_crst http://bugs.winehq.org/show_bug.cgi?id=4093
There is another "bug" in winealsa that leads to changing the size of the mmap-buffer (that makes a test in dsound fail) and at a first go I didn't find the proper function in alsa to set the buffer size. I didn't look further into this as it's pretty easy to set a buffer size with alsa dmix. (The buffer size needs to be a multiple of any sample size we will use, so that we don't need to change the size to avoid a remainder. Thas is because we can't have fractions of samples and the buffer is looped over so just not using part of it does not work either.)
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
To fix bug #4093 we need to replace the currently used signal callback method (very complex to make signals work properly [in Wine], thus we should avoid it) with I guess a fd based method for example with select. The alsa-api documentation about this looks pretty usable.
There are still frequent other problems with sound (especialy with dsound), but together with something like "SetThreadPriority" I found most sound is quite ok. http://wiki.winehq.org/SetThreadPriority
Jan
Jan Zerebecki wrote:
To fix bug #4093 we need to replace the currently used signal callback method (very complex to make signals work properly [in Wine], thus we should avoid it) with I guess a fd based method for example with select. The alsa-api documentation about this looks pretty usable.
Would that fix the DSOUND_MixOne underrun problem, too? Or is that a different bug?
tom
On Mon, Sep 18, 2006 at 02:12:02PM +0200, Tomas Carnecky wrote:
Jan Zerebecki wrote:
To fix bug #4093 we need to replace the currently used signal callback method (very complex to make signals work properly [in Wine], thus we should avoid it) with I guess a fd based method for example with select. The alsa-api documentation about this looks pretty usable.
Would that fix the DSOUND_MixOne underrun problem, too? Or is that a different bug?
No, as far as I understand this, that might (partially) be a dsound bug (if it is a bug) that gets worse when the thread that handles dsound doesn't get enough cpu (or not at the right time). A couple of weeks ago on IRC Roderick Colenbrander ( Thunderbird ) dug out some old incomplete patch that seemed as if it was intended to fix part of this, but it seemed not to work (deadlock) and I don't think anyone tried futher. Using the SetThreadPrio patch makes this problem much less noticable. Anyway this has only so much to do with winealsa as different sound backends provoke different scheduling by the kernel (like oss, jack and alsa; but this is also true for different ways to use alsa-lib [so the fd-based method may give us "better" scheduling]).
Jan
Aaron Slunt wrote:
Hi,
I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well.
My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly?
Thanks.
I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start.
I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together.
James
On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote:
I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start.
Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html )
I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together.
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change.
It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works.
Jan
Jan Zerebecki wrote:
On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote:
I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start.
Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html )
I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together.
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change.
It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works.
Jan
Jan, could you please clarify what you mean by an fd-based method? Thanks.
Aaron Slunt wrote:
Jan Zerebecki wrote:
On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote:
I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start.
Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html )
I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together.
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change.
It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works.
Jan
Jan, could you please clarify what you mean by an fd-based method? Thanks.
I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. If a windows application wants 44.1kHz, I would suggest that you add your own resampling code to wine. The reason for this is that a Linux application can ask for some buffer size from the alsa-lib. If the sound card hardware cannot do that buffer size in hardware, alsa-lib will reject the request and leave it to the application to try a different value. This is all ok for an open source application, as one can just fix the application to act accordingly. This is not the case with a binary application like all the applications running on top of wine. One cannot fix those applications to work nicely with alsa-lib. As a majority of sound card hardware works nicely at 48kHz, but very few sound cards do 44.1kHz in hardware, the application must then do the resampling necessary to achieve the task. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling.
James
James Courtier-Dutton wrote:
I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate.
alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib.
What are the constraints?
In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon.
Seems to me that it would take less development resources to fix an existing resampling implementation with known restraints, than to code a new one. Also it would end up helping more people.
If someone from the Wine community wants to fix the existing ALSA resampler, what needs to be done?
As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling.
What sound API is used on Mac OS X? Does that API require Wine to do resampling, or do things work OOTB there?
Molle Bestefich wrote:
James Courtier-Dutton wrote:
I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate.
alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib.
What are the constraints?
In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon.
Seems to me that it would take less development resources to fix an existing resampling implementation with known restraints, than to code a new one. Also it would end up helping more people.
If someone from the Wine community wants to fix the existing ALSA resampler, what needs to be done?
As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling.
What sound API is used on Mac OS X? Does that API require Wine to do resampling, or do things work OOTB there?
The possible so called "fix" is still a long way off. It requires a lot of work. As there are only a few alsa developers, that means it will take a long time. We each have rather long TODO lists currently and would welcome any offer to help ALSA development. Resampling is not a simple problem to fix. The technically best solution is for the application to do the resampling before passing it to the sound card, so any effort to do it in the sound drivers is always going to be sub-optimal, with sound quality suffering. The current alsa method achieves resampling with minimal effort, but presents some constraints to the application. These "constraints" are only a problem for closed source applications. In order to reduce the "constraints" so that ALSA works better with wine will result in trade offs. I.e. better compatibility with binary only application, but increased sound latency due to the required extra double buffers. I will document the "constraints" when I get a moment.
James
James Courtier-Dutton wrote:
The technically best solution is for the application to do the resampling before passing it to the sound card, so any effort to do it in the sound drivers is always going to be sub-optimal, with sound quality suffering.
I still fail to see how that's the case for Wine, specifically.
Doing the resampling in software in ALSA is surely just as good as doing the same resampling in software in Wine, right?
I will document the "constraints" when I get a moment.
Cool ;-).
On Mon, Sep 18, 2006 at 01:54:26AM -0400, Aaron Slunt wrote:
Jan, could you please clarify what you mean by an fd-based method? Thanks.
On http://alsa-project.org/alsa-doc/alsa-lib/pcm.html search for the headline "Event waiting routines". That is what I meant with fd-based method. Below that is "Asynchronous notification" and it describes what we currently use in winealsa.
Jan
Jan Zerebecki wrote:
On Mon, Sep 18, 2006 at 01:54:26AM -0400, Aaron Slunt wrote:
Jan, could you please clarify what you mean by an fd-based method? Thanks.
On http://alsa-project.org/alsa-doc/alsa-lib/pcm.html search for the headline "Event waiting routines". That is what I meant with fd-based method. Below that is "Asynchronous notification" and it describes what we currently use in winealsa.
Jan
I don't think asynchronous notification works at all well. There are several polling methods that can be used. 1) block on poll Used in jackd and generally considered the best method currently. It is often called the "callback" method where one has a thread block on the poll, and then call the "callback" function when triggered. jackd expands on this idea letting multiple different applications "callback" functions be called per trigger event.
2) let the audio buffer free wheel and use a timer to periodically fill/drain the buffers. (what ex windows apps/games tend to do. E.g. Doom3.)
The current asynchronous method uses signals and as a result does not tend to work at all well.
James
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected.
Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread?
tom
On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote:
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected.
Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread?
Yes, we cannot execute code in signals, namely critical sections cannot be entered recursively from a signal handler.
Blocking the signal was not accepted by Alexandre, so we would need to use something else ;)
Ciao, Marcus
On Wed, Sep 20, 2006 at 05:55:03PM +0200, Marcus Meissner wrote:
On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote:
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected.
Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread?
It is because how (all) signals work and how wine works. The fd method may not require a separate thread when we can combine the event loop of the currently used sound thread with e.g. the select for the alsa-lib fd(s), thu I didn't look at that and it might not be possible.
Yes, we cannot execute code in signals, namely critical sections cannot be entered recursively from a signal handler.
Blocking the signal was not accepted by Alexandre, so we would need to use something else ;)
I later noticed that the signal blocking patch also didn't work as expected (for e.g. War3 I got many buffer underruns) because it seemed to use much cpu (so It might have only mitigated the race condition...).
Also as I understood from what AJ said, the issue is more complex. He mentioned that it would be possible to make it work, but we agreed that when there is an easier and more straight forward solution it should be preferred. (Another problem I remember is that the sigaction callback can trigger in any thread which seems to be something we realy want to avoid.)
Jan
Jan Zerebecki wrote:
On Wed, Sep 20, 2006 at 05:55:03PM +0200, Marcus Meissner wrote:
On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote:
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected.
Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread?
It is because how (all) signals work and how wine works. The fd method may not require a separate thread when we can combine the event loop of the currently used sound thread with e.g. the select for the alsa-lib fd(s), thu I didn't look at that and it might not be possible.
this looks very possible to me... and likely the cleanest solution in the event loop we only wait on a single item (the fd used for signaling a new event to be handled by the thread), so adding a poll on a second fd seems very feasible (alternative coding with win32 objects is also possible, though a bit more trickier, but this could be dropped IMO, as it's currently broken -> on event is lost if two are pushed before the playback thread gets a chance to get them)
On Mon, Sep 18, 2006 at 01:58:59AM +0200, Jan Zerebecki wrote:
I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html )
It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works.
The intention is to get the same buffer size (in bytes) for different formats, because dsound expects this (according to our dsound tests).
I tried with the attached patch but snd_pcm_hw_params_set_buffer_size_near sets different than the requested size and snd_pcm_hw_params_set_buffer_size doesn't work at all. I don't know if this is because I am not familiar with the api or because of a bug in it. Can anyone shed some light on this who is more familiar with the alsa-lib api?
Jan
-
Aaron Slunt -
Eric Pouech -
James Courtier-Dutton -
Jan Zerebecki -
Marcus Meissner -
Molle Bestefich -
Tom Spear -
Tom Wickline -
Tomas Carnecky