Re: interactive dsound tests fail && winealsa problem
I'm trying to improve winealsa's sound quality, and I have found a way. And I think I should make some checks in configure which I am totally unaware of. If everything go smooth, the patch will be sent out within several days.
A few weeks back, I got fed up with the winealsa driver not working with my app (and the OSS driver wasn't working for me at the time either), so I gutted it and rolled my own using the DMIX plugin. PCM output is about 80% complete ATM. All that's left to do there is one-shot buffers, hook up volume/panning control, and do some tidying up of the code. And then there's the input side.... I was planning to submit it as a separate driver, since its architecture differs significantly from the existing one. The main differences are: support for "hardware" secondary buffers with ALSA, not Wine, doing the mixing; and the use of the DMIX plugin, which hopefully will allow it to play friendly with other DMIX-aware linux apps (e.g. mplayer, etc.). So, what I'm wondering now is: 1) Should I bother finishing it? OSS is working fine for me again, and if someone else is going to fix the existing ALSA driver...., and 2) if the answer to question 1 is 'yes', then what is the proper protocol for submitting such a substantial code change. IMO a separate driver would be less destabilizing (don't run it if you don't want to!), but a little confusing (two ALSA drivers?).
I have hardware secondary buffers almost working with OSS and soundcards that supports multi opens. I haven't had the time to finish it lately but I would like to see how you handled some of the dsound.dll issues. wine(a)frotz.org wrote:
I'm trying to improve winealsa's sound quality, and I have found a way. And I think I should make some checks in configure which I am totally unaware of. If everything go smooth, the patch will be sent out within several days.
A few weeks back, I got fed up with the winealsa driver not working with my app (and the OSS driver wasn't working for me at the time either), so I gutted it and rolled my own using the DMIX plugin. PCM output is about 80% complete ATM. All that's left to do there is one-shot buffers, hook up volume/panning control, and do some tidying up of the code. And then there's the input side....
I was planning to submit it as a separate driver, since its architecture differs significantly from the existing one. The main differences are: support for "hardware" secondary buffers with ALSA, not Wine, doing the mixing; and the use of the DMIX plugin, which hopefully will allow it to play friendly with other DMIX-aware linux apps (e.g. mplayer, etc.).
So, what I'm wondering now is: 1) Should I bother finishing it? OSS is working fine for me again, and if someone else is going to fix the existing ALSA driver...., and 2) if the answer to question 1 is 'yes', then what is the proper protocol for submitting such a substantial code change. IMO a separate driver would be less destabilizing (don't run it if you don't want to!), but a little confusing (two ALSA drivers?).
On Wed, 2003-09-24 at 08:26, wine(a)frotz.org wrote:
I was planning to submit it as a separate driver, since its architecture differs significantly from the existing one. The main differences are: support for "hardware" secondary buffers with ALSA, not Wine, doing the mixing; and the use of the DMIX plugin, which hopefully will allow it to play friendly with other DMIX-aware linux apps (e.g. mplayer, etc.).
Yes, submit! I'd love this, dmix is really the future of Linux audio I think. One thing I don't understand is why the drive had to be rewritten to use it, I thought dmix was a userspace plugin to libalsa?
wine(a)frotz.org writes:
So, what I'm wondering now is: 1) Should I bother finishing it? OSS is working fine for me again, and if someone else is going to fix the existing ALSA driver...., and 2) if the answer to question 1 is 'yes', then what is the proper protocol for submitting such a substantial code change. IMO a separate driver would be less destabilizing (don't run it if you don't want to!), but a little confusing (two ALSA drivers?).
No I don't think we want two ALSA drivers, we want one that works right in all cases. -- Alexandre Julliard julliard(a)winehq.com
On Wednesday 24 September 2003 10:55 am, Alexandre Julliard wrote:
wine(a)frotz.org writes:
So, what I'm wondering now is: 1) Should I bother finishing it? OSS is working fine for me again, and if someone else is going to fix the existing ALSA driver...., and 2) if the answer to question 1 is 'yes', then what is the proper protocol for submitting such a substantial code change. IMO a separate driver would be less destabilizing (don't run it if you don't want to!), but a little confusing (two ALSA drivers?).
No I don't think we want two ALSA drivers, we want one that works right in all cases.
Nevertheless, I don't see how it could be a bad thing to post your code here on wine-devel; that way others could at least borrow from your code. Alternatively, finish the driver, and if it's better than the existing one, perhaps it should replace it... wine-devs including AJ cannot possibly know if your code is better or worse, or how to use it or not use it, without seeing it. I agree that two drivers is silly but that doesn't mean your code cannot be used in some other way... there may be some other problem for all I know, but the two-drivers thing is a red herring. Don't let that stop you from sharing the fruits of your labor, if that is what you want to do... -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
participants (5)
-
Alexandre Julliard -
Gregory M. Turner -
Mike Hearn -
Robert Reif -
wine＠frotz.org