Implement THREAD_PRIORITY_TIME_CRITICAL

Willie Sippel willie at zeitgeistmedia.net
Sat Apr 1 10:21:19 CST 2006


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 <willie at 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
> >
> > <willie at froq.net>

-- 
Willie Sippel

  ////////  |  Tritium Studios
 //         |  ______________________________
//// ///    |  http://www.tritium-studios.com

<willie at froq.net>



More information about the wine-devel mailing list