Hello,
I have been trying to get audio working in sync with the game I am playing (Activision Call of Duty)
I get this error:
err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config
If I use the suggestion i get 1sec lag on in-game sounds. Someone #winehq gave me some tips.
I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please?
[dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users
;; HEL only: Number of waveOut fragments ahead to mix in new buffers. "HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Forces emulation mode (using wave api) "HardwareAcceleration" = "Emulation"
;; Sets default playback device (0 - number of devices - 1) ;"DefaultPlayback" = "0" ; use first device (/dev/dsp) ;"DefaultPlayback" = "1" ; use second device (/dev/dsp1) ;"DefaultPlayback" = "2" ; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;"DefaultCapture" = "0" ; use first device (/dev/dsp) ;"DefaultCapture" = "1" ; use second device (/dev/dsp1) ;"DefaultCapture" = "2" ; use third device (/dev/dsp2)
Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise)
I wonder if this is a known problem (bug)? Is there a work around? Or a fix please?
I am not on this list, so please include my email address in any replies.
Kind regards JG
On 5/6/05, J. Grant jg@jguk.org wrote:
I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please?
There is basically no documentation on the config file.
[dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users
Those should not be in [dsound] but in [winmm]. Try ALSA or OSS. Could make a difference. You could also set UseMmap to n in [wineoss] when using that.
Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise)
It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from.
Paul
Hi,
On Sat, May 07, 2005 at 10:00:59AM +0200, Paul van Schayck wrote:
It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from.
BTW, I'm planning to implement SetThreadPriority(). Maybe it actually gets called by the game (but at least it should get called by our multimedia DLLs in recent CVS now).
This could also help a lot, provided that you're running on a SCHED_ISO and SCHED_BATCH aware kernel...
Of course this SetThreadPriority() implementation wouldn't be perfect, but at least it would be a first implementation to see whether it helps, and in that case one could do further discussion with Con Kolivas to try to make Linux almost fully compatible with the Windows thread priority model.
Andreas Mohr
Hi Andreas,
Thank you for your quick response.
On 07/05/05 10:49, Andreas Mohr wrote:
Hi,
On Sat, May 07, 2005 at 10:00:59AM +0200, Paul van Schayck wrote:
It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from.
BTW, I'm planning to implement SetThreadPriority(). Maybe it actually gets called by the game (but at least it should get called by our multimedia DLLs in recent CVS now).
This could also help a lot, provided that you're running on a SCHED_ISO and SCHED_BATCH aware kernel...
Okay, great! I am running debian sarge 2.6.8-2-k7 kernel, not sure if that is SCHED_ISO and SCHED_BATCH aware, but I can upgrade to the latest kernel in debian testing/sarge if necessary.
Of course this SetThreadPriority() implementation wouldn't be perfect, but at least it would be a first implementation to see whether it helps, and in that case one could do further discussion with Con Kolivas to try to make Linux almost fully compatible with the Windows thread priority model.
Hopefully it would give some improvement.
I am not on this list, please include my email address in any replies.
Kind regards JG
Hi,
On Sat, May 07, 2005 at 12:13:00PM +0100, J. Grant wrote:
On 07/05/05 10:49, Andreas Mohr wrote:
Okay, great! I am running debian sarge 2.6.8-2-k7 kernel, not sure if that is SCHED_ISO and SCHED_BATCH aware, but I can upgrade to the latest kernel in debian testing/sarge if necessary.
Haha, good joke. That stuff will require a REAL self-made kernel, a -ck one with that improved scheduling and much better interactivity, probably best to grab the 2.6.11-ck8 patch version, from http://members.optusnet.com.au/ckolivas/kernel/
(normal kernels don't have non-root realtime scheduling, due to very tricky implementation of usually easily DoS-able realtime priorities)
Hopefully it would give some improvement.
You'd be able to test it now, with my very preliminary proof-of-concept patch that is attached (it's not tested since I currently don't know of any software/game that uses SetThreadPriority()). Also, testing would best be done based on known-to-be-problematic games. If this patch together with a SCHED_ISO-capable kernel makes a real difference, then we have something that we should continue to work on.
OK, again, you need: - 2.6.X-ckX kernel (the ones with SCHED_ISO, SCHED_BATCH support) - rather current (CVS) Wine, since it requires the SetThreadPriority patches in various multimedia/sound threads in Wine - my patch in that Wine - one or better several preferrably problematic game(s) with in-game lags or sound distortion etc. pp.
And of course you should first run the game *without* my patch, since the -ck kernel may very well significantly improve game behaviour anyway (or actually deteriorate it), so the test basis is VERY different from running a normal kernel and this should be taken into account properly, otherwise you can just bin those test findings. :)
I'm interested in test results from as many people as possible, preferrably people with a good (excessive?) gaming background ;)
The best result would be to have this patch dramatically improve lag or sound or graphics interactivity in games in a recent CVS Wine version on a -ck kernel, compared to exactly the same environment *minus* my SetThreadPriority() patch.
One last thing: you might have to change the unix_tid in the patch into unix_pid in case it fails with the unmodified patch.
Please report any changes you observe.
Have fun,
Andreas Mohr
Hi Paul Thank you for your quick response
On 07/05/05 09:00, Paul van Schayck wrote:
On 5/6/05, J. Grant jg@jguk.org wrote:
I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please?
There is basically no documentation on the config file.
I did find "man wine.conf", however that is quite incomplete it seems.
Also these files:
22 /usr/share/doc/wine/config -> ../../wine/skel/config 8050 /usr/share/wine/skel/config
This FAQ entry http://www.winehq.com/site/docs/wine-faq/index ======================== 5.3. How do I configure Wine to run on my system?
Wine requires that you have a config file as ~/.wine/config. The format of this file is explained in the wine.conf man page. The file documentation/samples/config ( http://source.winehq.org/source/documentation/samples/config) contains a config file example. More explicit directions can be found in the README file ( http://source.winehq.org/source/README) that will be located in the base Wine directory after you gunzip and untar the distribution file. ====================
I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page?
The other area of document which I think could be improved is "man wine". For instance Call of Duty would not run with whatever was the default "Windows" that resulted when no override in [Version] section of ~/.wine/config
So I had to create one with this:
[Version] "Windows"="win2k"
I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?)
I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please?
[dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users
Those should not be in [dsound] but in [winmm]. Try ALSA or OSS. Could make a difference. You could also set UseMmap to n in [wineoss] when using that.
ok, thank you. Sorry I got them in the wrong section, I was just guessing as I had not found any complete documentation then.
I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to "1" but it did not seem to make any difference to the audio lag unfortunately.
Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise)
It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from.
By "emulation" do you simply mean that the dsound api is wrapped, and then the data passed to ALSA or OSS etc? Or do you mean that there is a significant amount of dsound "emulation" processing on the data before it is passed to ALSA or OSS etc?
Is it very common to have this lag? I am using a 2.2Ghz AlthonXP 32bit (3200+) with 1GB ram.
I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common?
I am not on this list, please include my email address in any replies.
Kind regards JG
On 5/7/05, J. Grant jg@jguk.org wrote:
I did find "man wine.conf", however that is quite incomplete it seems.
Incomplete and not to be trusted on accurate information.
I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page?
No, we are dropping the config file completely. And as heads up, there will be no conversion tool to the new system. As Alexandre said: "we should stop being nice [in this conversion period]".
The config will be moved to the registry and winecfg.
I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?)
That option was dropped a bit over a year ago.
I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please?
There is no list of options in the first place right now. With the system we will be looking into creating a tool that will grab all options from the source code so we can keep the list up to date.
I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to "1" but it did not seem to make any difference to the audio lag unfortunately.
Both the [wineoss] and [winealsa] options have never been documented. The normal behaviour though with a lack of performance and dsound is not lag but cliping sound. So I don't think it's a performance issue.
I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common?
Set the [winmm] "drivers" option to nothing. You won't get any sound at all. Is the lag now less?
Paul
On 07/05/05 14:54, Paul van Schayck wrote:
On 5/7/05, J. Grant jg@jguk.org wrote:
I did find "man wine.conf", however that is quite incomplete it seems.
Incomplete and not to be trusted on accurate information.
Is there a reason the man page does not state that?
I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page?
No, we are dropping the config file completely. And as heads up, there will be no conversion tool to the new system. As Alexandre said: "we should stop being nice [in this conversion period]".
The config will be moved to the registry and winecfg.
Until it is it would be very useful to have it documented.
is there a reason the man page does not state it is not required anymore?
Presently it states "wine expects a configuration file"
I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?)
That option was dropped a bit over a year ago.
So how can I set the winver when I run an program from the command prompt?
I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please?
There is no list of options in the first place right now. With the system we will be looking into creating a tool that will grab all options from the source code so we can keep the list up to date.
I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to "1" but it did not seem to make any difference to the audio lag unfortunately.
Both the [wineoss] and [winealsa] options have never been documented. The normal behaviour though with a lack of performance and dsound is not lag but cliping sound. So I don't think it's a performance issue.
I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common?
Set the [winmm] "drivers" option to nothing. You won't get any sound at all. Is the lag now less?
Does the case not matter?
err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config file
^^ had to turn this back on.
then there was sound again, so I could not test.
please include my email address in replies.
Kind regards JG
Le sam 07/05/2005 à 08:45, J. Grant a écrit : [snip]
I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page?
The exact place where files are in your filesystem is package dependant. Wine (the source tarball from winehq) doesn't use /usr/share/wine/skel/config, It actually defaults to /usr/local, and
[snip]
I am not on this list, please include my email address in any replies.
After posting so many messages, maybe it'd be a good idea to subscribe. You can always consult the posts via the Web, and it'll make the job of our mailing list moderator easier (plus you'd get faster answers).
Vincent
-
Andreas Mohr -
J. Grant -
Paul van Schayck -
Vincent Béron