My plans for SOC

[Maarten Lankhorst]

For the summer of code I'm planning to improve the dsound code and alsa
code, to make alsa finally better then OSS, in a way that has a will get
accepted into the wine tree, for that I'm thinking of improving on the
following fronts:

Winealsa:
- Add mixer device and aux controls
- Implement dsound capture
- Seperate the initialisation of the directsound code from the waveout
code, to allow creation of multiple dmix devices.
- Try to configure alsa to allow arbitrarily big buffers, working around
the alsa problem that only up to a certain amount can be allocated for
buffers, certain programs (for example winamp) may require more.
- Remove the queuing thread and use Lock() and Unlock() instead.
- Make it run so well, people wouldn't want to use OSS any more.

Both dsound/winealsa:
- Allow proper usage of Lock() and Unlock() for sound drivers, it's not
used properly or even tested in current dsound code.
- Rework some of the dsound code, to allow mixing to be done in
winealsa, and fix possible errors that can be caused by it.
- Improve the dsound software mixer code to allow mixing and (if
possible) be less prone to buffer underruns.

The challenge is to get this working right, without too much of an
impact hit. I also will have to work around alsa limitations: I cannot
make buffers arbitrarily big, while in windows they can be. It seems no
2 programs use dsound in the same way, so I will have to test with
various different programs to get everything working.

I'll try to get in contact with alsa-devel first, if there is a way to
change buffer size to something arbitrary, it is worth it in the long
run to use that method. A manual fix seems to be close everything using
alsa, then echo 256 > /proc/asound/card0/pcm0p/sub0/prealloc, but I am
hoping there is an easier way to fix it, in either case I am afraid I
will have to put some memory buffer code in winealsa as fallback.

If there's still some time left, I'll also try to get some 3d sound code
in, using some openal code, the license seems to be lgpl compatible, or
I will try to get support for multiple (4, 5.1 ?) speakers working, it
depends a little on how fast I can get this to work in a nice shape.

Looking for feedback.

Cheers,
Maarten

[Tomas Carnecky]

Maarten Lankhorst wrote:
> - Remove the queuing thread and use Lock() and Unlock() instead.

There has to be a thread somewhere: for buffers that are DSBPLAY_LOOPING.

tom

[Bryan Haskins]

Frankly if you could get ALSA working perfectly, and DSOUND to do what it's
supposed to without underruns (As in WoW, with default settings) You would
make my life a lot easier. I answer so many questions about sound it's not
even funny. Out of the box "Just working" sound would be pretty great.  OSS
is *alright* and all but it doesn't work so well with software mixing, ALSA
however is easy to set up.

On 3/13/07, Maarten Lankhorst  wrote:
> For the summer of code I'm planning to improve the dsound code and alsa
> code, to make alsa finally better then OSS, in a way that has a will get
> accepted into the wine tree, for that I'm thinking of improving on the
> following fronts:
>
> Winealsa:
> - Add mixer device and aux controls
> - Implement dsound capture
> - Seperate the initialisation of the directsound code from the waveout
>
> code, to allow creation of multiple dmix devices.
> - Try to configure alsa to allow arbitrarily big buffers, working around
>
> the alsa problem that only up to a certain amount can be allocated for
> buffers, certain programs (for example winamp) may require more.
> - Remove the queuing thread and use Lock() and Unlock() instead.
> - Make it run so well, people wouldn't want to use OSS any more.
>
> Both dsound/winealsa:
> - Allow proper usage of Lock() and Unlock() for sound drivers, it's not
>
> used properly or even tested in current dsound code.
> - Rework some of the dsound code, to allow mixing to be done in
>
> winealsa, and fix possible errors that can be caused by it.
> - Improve the dsound software mixer code to allow mixing and (if
>
> possible) be less prone to buffer underruns.
>
> The challenge is to get this working right, without too much of an
> impact hit. I also will have to work around alsa limitations: I cannot
> make buffers arbitrarily big, while in windows they can be. It seems no
> 2 programs use dsound in the same way, so I will have to test with
> various different programs to get everything working.
>
> I'll try to get in contact with alsa-devel first, if there is a way to
> change buffer size to something arbitrary, it is worth it in the long
> run to use that method. A manual fix seems to be close everything using
> alsa, then echo 256 > /proc/asound/card0/pcm0p/sub0/prealloc, but I am
> hoping there is an easier way to fix it, in either case I am afraid I
> will have to put some memory buffer code in winealsa as fallback.
>
> If there's still some time left, I'll also try to get some 3d sound code
> in, using some openal code, the license seems to be lgpl compatible, or
> I will try to get support for multiple (4, 5.1 ?) speakers working, it
> depends a little on how fast I can get this to work in a nice shape.
>
> Looking for feedback.
>
> Cheers,
> Maarten

[Stefan Dösinger]

Am Dienstag 13 März 2007 15:32 schrieb Maarten Lankhorst:
> For the summer of code I'm planning to improve the dsound code and alsa
> code, to make alsa finally better then OSS, in a way that has a will get
> accepted into the wine tree, for that I'm thinking of improving on the
> following fronts:
> ...

Sounds like a lot of coding for you this summer :-)