My plans for SOC
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
Re: My plans for SOC
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
Re: My plans for SOC
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 [EMAIL PROTECTED] 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 -- Cheers, Bryan
Re: My plans for SOC
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 :-) pgphj503Ck2UK.pgp Description: PGP signature
