Am Samstag, 1. April 2006 00:00 schrieb Chris Morgan: > 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. > OK, but it should work with cards that do hardware acceleration then (eg, SB Audigy), with emulation disabled and acceleration set to full? Another idea could be to use realtime-lsm I think (grants realtime permissions to specific non-root users or groups)? It's quite common, anyway, even if it's not part of the mainline kernel right now...
So, Wine could be set to a specific group (wine or audio), and we recommend to install realtime-lsm and set it up for the wine group - that should do the trick without having to run as root? Optimizing DSound and the sound drivers, as well as increasing the buffer size, is definitely another (complementary) option... > Chris > > On 3/31/06, Willie Sippel <[EMAIL PROTECTED]> 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 > > > > <[EMAIL PROTECTED]> -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <[EMAIL PROTECTED]>