Hi =)
I have ALSA 0.9 with OSS compat modules. I recently got DeusEx to run (on Wine w/ openGL, not talking about WineX) However using winealsa.drv sound is very laggy and lots of nasty clicks and hissing occurs, but if I use wineoss.drv sound is fine?? (note OSS driver will be talking to ALSA via the snd-pcm-oss compat module)
Also when using the wineoss module and the game (not just DeusEx but most games I got working) is setting up sound it seems to freeze, all i do then is ctrl+z, fg, in controling term and things run fine from then on.
-TJ
TJ a écrit :
Hi =)
I have ALSA 0.9 with OSS compat modules. I recently got DeusEx to run (on Wine w/ openGL, not talking about WineX) However using winealsa.drv sound is very laggy and lots of nasty clicks and hissing occurs, but if I use wineoss.drv sound is fine??
the way the wine OSS driver and the wine Alsa driver control streaming data to the sound card is a bit different, so it's possible to get different effects thru different wine drivers. I'm not telling that Alsa behavior is correct :-( setting this correctly isn't trivial, because it also depends on lots of factors: - how the program sends its sounds bits - how your current system is loaded - ... not so many people work on Alsa 0.9 these days, so if you want to give it a shot, be welcome
A+
I never looked into programming ALSA or WINE I know C, but not much beoynd some GTK can console stuff. (ie will need to learn the APIs involved in this)
But I do have a SBLive with fully working MIDI (via ALSA) and i'd love to help testing/feedback (and get FFVII to work which demands MIDI)
not so many people work on Alsa 0.9 these days, so if you want to give it a shot, be welcome
well 0.5 is deprecated and unsuported, afaik all major distros have now switched to 0.9, also ALSA has gone into the Linux kernel. It is more complete then OSS, ie more drivers, midi support etc. (with OSS you need buy the whole opensound system from 4front and I not a fan of semi-free stuff like OSS/free)
call on me for help, but I feel if I were try solve it my self I would be playing catch-up with those who understand it better then I. Saying that I will go look at some docs and the source to see what I can see.
maybe compare how snd-pcm-oss streams the sound to alsa, with how winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does a better job of it =)
-TJ
maybe compare how snd-pcm-oss streams the sound to alsa, with how winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does a better job of it =)
beware that the APIs (OSS and ALSA) are rather different moreover, ALSA 0.9 driver has a still to be improved dsound interface (which may be the cause of your issues here) A+
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, sorry for the delay in my answer, but my mail server was down...
I've worked on the ALSA 0.9 driver for wine, and I know it has problems. I was planning to restart to work on it in the past weeks but, due to my job, I haven't been able to do it.
Right now, I'm going on vacation and I'll be back 4 weeks from now. I think I'll we able to restart coding around the first week of October. Before then, I'm not sure I'll be able to check my e-mail since I'll be "on the road" (literally :-) I'll be travelling along the old Route 66 during these weeks... :-)
Feel free to try by yourself in the mean time. The code in itself is not so hard to understand. It is more difficut to get a grip on how the windows applications are using the DSOUND interface.
On Sun, 1 Sep 2002, TJ wrote: [snip]
maybe compare how snd-pcm-oss streams the sound to alsa, with how winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does a better job of it =)
this is how it has been done... :) but, there are still few issues that need to be worked out, mainly because the oss layer is really a kernel thing, so it has access to the internals of the alsa driver, while we are accessing the driver from its published interface.
basically, we need a way to get feedback from the kernel driver about how much portion of the enqueued sound has already been played. And we need to check how to relate the written bytes and played bytes that the Windows application wants to track through the DSOUND_GetPosition() call.
The current way to evaluate those values from the "current position" we have got from the alsalib (which BTW is really an hack, since we are using an internal variable of the library through an internal function which IIRC is not part of the public API of the alsalib.
I would like to test something different, like the secondary buffer approach, but it isn't so simple.
BTW, we have been contacted by one of the ALSA developer who was willing to work on the driver, so I hope to be able to do something with his help when I'll be back.
-TJ
bye,
/pietrobo
- -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. - ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ?
-
Eric Pouech -
Marco Pietrobono -
TJ