Just using the jack audio driver won't ensure that we won't see stuttering sound. If dsound is performing hardware emulation then it has its own internal thread that is performing mixing and other dsound events. If this thread gets held off then you'll have no sound to give to the jack audio drive when it runs.
Increasing the size of this dsound buffer and ensuring that it runs seems like the easiest ways to fix issues with the dsound thread being held off and should work for all audio interfaces assuming their threads also run reliably.
Chris
On 3/31/06, Willie Sippel willie@zeitgeistmedia.net wrote:
Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn:
Until it crashes your box of course...
If a Windows program has a habit of hard freezing the system then the user will learn not to run that program.
As it is, right now _many_ games suffer this problem with corrupted audio and it's very unpleasant (loud bursts of white noise). Makes the games unplayable, in fact.
I'd rather make the games playable and give developers an incentive to find a better privilege model than leave this to coast along for another few years with only a bunch of talk, ideas and non-mainline patches.
Right now there are no good solutions for this we can implement in Wine itself (except maybe making wineserver suid root and drop privs), and SCHED_ISO isn't merged into the mainline kernel, so telling users to upgrade won't solve much.
I'm probably wrong, but in theory, if Wine used the Jack audio driver, and jackd is suid root, the sound shouldn't stutter but Wine/ a Windows app still couldn't hard-lock the system, as Wine would run with standard user privileges? If that's the case, wouldn't fixing the Jack driver and making it the preferred output plugin solve the issue? I mean, it's at least as conveniant as suggesting to run Wine as root... ;-)
-- Willie Sippel
//////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com