Hi,
On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote:
This patch gives me rock solid audio in Imperium Galactica 2, so now the game works perfectly.
There has been discussion around this issue with respect to security in the past, however, regardless of what approach is adopted this code will have to be written anyway.
Ah, thanks, nice to see that it actually helps.
scheduler = SCHED_FIFO;
IMHO we should really add some smart detection of SCHED_ISO kernel capability and *much* prefer to use that one then. One really wouldn't want to hang the box... Not to mention that SCHED_FIFO requires root, which is an absolute PITA.
Nice To Have would be support for stuff such as SCHED_IDLEPRIO and SCHED_BATCH...
- if (result == -EPERM)
- {
static int need_warning = 1;if (need_warning){fprintf( stderr, "\nwineserver: Failed to promote the priority of a time critical thread.\n" );fprintf( stderr, "Audio may destabilise. To fix this re-run the application as root.\n\n" );need_warning = 0;}return;- }
Make that static int already_warned; /* static: = 0! */
Since static uses 0 as default and you don't want to waste space in the .bss(?) segment for an explicit 1 init.
Andreas Mohr
On Fri, 31 Mar 2006 15:21:51 +0200, Andreas Mohr wrote:
IMHO we should really add some smart detection of SCHED_ISO kernel capability and *much* prefer to use that one then. One really wouldn't want to hang the box...
Sure, feel free to add it after this basic universal support has gone in :) Right now SCHED_ISO is only available in the -ck kernels right?
Not to mention that SCHED_FIFO requires root, which is an absolute PITA.
Not really.
su -c 'wine IG2.exe'
It's not all that inconvenient :)
Nice To Have would be support for stuff such as SCHED_IDLEPRIO and SCHED_BATCH...
Sure. But for now this will start off OK.
Make that static int already_warned; /* static: = 0! */
Since static uses 0 as default and you don't want to waste space in the .bss(?) segment for an explicit 1 init.
Good catch. Alexandre, could you modify that as you commit?
thanks -mike
Mike Hearn mike@plan99.net writes:
Not to mention that SCHED_FIFO requires root, which is an absolute PITA.
Not really.
su -c 'wine IG2.exe'
It's not all that inconvenient :)
Until it crashes your box of course... I really don't think we want to encourage running as root, or give Windows apps a way to screw up the system. If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-)
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.
If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-)
I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can.
thanks -mike
Can't we use kernel capabilities to let people do this without having to run as root? Thats what jack audio server users are advised to do to ensure SCHED_FIFO.
Chris
On 3/31/06, Mike Hearn mike@plan99.net wrote:
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.
If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-)
I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can.
thanks -mike
On Fri, 31 Mar 2006 16:47:48 -0500, Chris Morgan wrote:
Can't we use kernel capabilities to let people do this without having to run as root? Thats what jack audio server users are advised to do to ensure SCHED_FIFO.
Could be - there are lots of options for doing this without root access. Apart from the warning which is easy to delete, this patch doesn't require root. It just tries to set the scheduler, and prints a simple tip if it fails. So, whatever schemes are used, this patch is still needed.
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... ;-)
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
On Fri, 31 Mar 2006, Chris Morgan wrote:
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.
How can I do that? I'm experiencing lots of problem with Windows Media Player when using the Esound backend.
Regards,
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@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
Am Samstag, 1. April 2006 18:21 schrieb Willie Sippel:
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?
Just tested Mike's patch with realtime-lsm. Running Wine as regular user now gives perfect audio with no stutter for every application I tried so far. So yes, realtime-lsm actually does the trick - me happy! ;) I load realtime-lsm with "gid=18 mlock=1 allcaps=1" (gid 18 is audio), and set wineserver to root:audio. Easy solution, great results!
On Sun, 02 Apr 2006 03:49:39 +0200, Willie Sippel wrote:
Just tested Mike's patch with realtime-lsm. Running Wine as regular user now gives perfect audio with no stutter for every application I tried so far. So yes, realtime-lsm actually does the trick - me happy! ;)
Wonderful!
I load realtime-lsm with "gid=18 mlock=1 allcaps=1" (gid 18 is audio), and set wineserver to root:audio. Easy solution, great results!
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
Mike Hearn mike@plan99.net writes:
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
You're missing the point. The problem is not "how can we bypass system protections?", the problem is "how can we achieve what we want without having to bypass anything?". These things are restricted to root precisely because they can screw up the system, and that's not a power we want to give to random Win32 apps. What we need is a mechanism that is safe enough to be enabled by default on all systems, without requiring suid root or similar hacks.
Alexandre Julliard wrote:
Mike Hearn mike@plan99.net writes:
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
You're missing the point. The problem is not "how can we bypass system protections?", the problem is "how can we achieve what we want without having to bypass anything?". These things are restricted to root precisely because they can screw up the system, and that's not a power we want to give to random Win32 apps. What we need is a mechanism that is safe enough to be enabled by default on all systems, without requiring suid root or similar hacks.
Alex, I got one idea: Wine-level timeslicing. While this would be doing what the standard VM system in all OSes does already, it would allow for us to priortize processes within Wine, controlled by Wine.
You're missing the point.
It can screw things up on multi-user servers where uptime is important and you don't want just anybody to hang the box. I don't think it's a big deal on a desktop where the absolute worst case is you have to hit the reset button.
What we need is a mechanism that is safe enough to be enabled by default on all systems, without requiring suid root or similar hacks.
Yep, that'd be great, but I don't know of one. If anybody has any more suggestions please speak up!
SCHED_ISO has been proposed, but it's not in the mainline kernel and in one thread somebody writing a low-latency audio app found it didn't improve things enough. Con Kolivas said - sure, if your app needs SCHED_FIFO then that's what you have to use. So there's no guarantee this approach is viable.
Changing buffer sizes may be another alternative but nobody has written a patch for that, nor shown that it actually works and doesn't break apps in some other way.
So for these reasons, my opinion stays - I would rather we use and refine this known to work solution than wait for a perfect one to arrive, as in the meantime users will be saying "Oh Wine sucks for games, use Windows" or "Wine sucks for games, use Cedega". Which doesn't solve anything. If/when somebody comes up with a kernel patch or clever patch that removes the need for root, great! Let's use it.
Alex, I got one idea: Wine-level timeslicing. While this would be doing what the standard VM system in all OSes does already, it would allow for us to priortize processes within Wine, controlled by Wine.
Segin, I don't think that'd work, this is a variation on the "let's just drop the priority of every other thread" idea. The problem is that this doesn't have the same effect, the kernel still doesn't schedule the Wine threads often enough to get corruption-free audio.
There are two ways to attack this issue - either getting the kernel to schedule a TIME_CRITICAL thread often enough that it works without risk of freeze, or making Wines audio less susceptible to scheduling glitches.
The first one requires us to either use elevated privs, or find and implement some scheduling algorithm that gives us what we want. Our track record at getting big changes into other projects is poor and it will be years before it's widespread even if done tomorrow. The second one will break as much as it fixes: pro audio apps will never work properly when there is a high amount of latency, and it may interfere with games too (eg sound effects not matching what you see on screen).
It's a rock and a hard place, and we're stuck between them :(
On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
Mike Hearn mike@plan99.net writes:
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
You're missing the point. The problem is not "how can we bypass system protections?", the problem is "how can we achieve what we want without having to bypass anything?". These things are restricted to root precisely because they can screw up the system, and that's not a power we want to give to random Win32 apps. What we need is a mechanism that is safe enough to be enabled by default on all systems, without requiring suid root or similar hacks.
It does work without any special privileges on a kernel with the SCHED_ISO patch (included in -ck), because it can transparently exchanges SCHED_FIFO/RT with SCHED_ISO. A thread with SCHED_ISO can not outstarve the system because when using over 80% (default) cpu it's priority handling is revoked.
It also works fine on any system on that wine got the permission for SCHED_FIFO/RT, because when an App. behaves wrong (it's thread outstarves the rest of the system) a user can hit the magic-sysrq key combo for "disable SCHED_FIFO/RT for running processes". (I'm not sure if that magic-sysrq-key is available in mainline yet or only in -ck. Also note that on windows a base priority this high is able to outstarve the the system.)
About the "SCHED_FIFO/RT needs root"-problem: It does not. I think since Linux kernel 2.6.12 there is a new resource limit for realtime (think: ulimit). There are various ways to give wine an increased limit. Among them a suid helper called set_rlimits and using a up to date version of pam (newer version can set this limit). This is perhaps less critical than the process limit, which is I think per default on a Debian unlimited (think: fork bomb). This also seems to be _the_ solution for this problem in the (audio-)linux community.
So trying to use SCHED_FIFO and if it fails trying to use SCHED_ISO is safe for every system. (Not sure if that is the best order. A more complete patch would probably also take care of most of the other base priorities windows has by using SCHED_IDLE... SCHED_WINE anyone?) If the user chose to permit SCHED_FIFO/RT he is probably willing to risk needing to hit that magic-sysrq-key to disable it again. If he does not want to risk that he can use a kernel with SCHED_ISO.
Does this fit your requirement?
Jan
Jan Zerebecki wrote:
On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
Mike Hearn mike@plan99.net writes:
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
You're missing the point. The problem is not "how can we bypass system protections?", the problem is "how can we achieve what we want without having to bypass anything?". These things are restricted to root precisely because they can screw up the system, and that's not a power we want to give to random Win32 apps. What we need is a mechanism that is safe enough to be enabled by default on all systems, without requiring suid root or similar hacks.
It does work without any special privileges on a kernel with the SCHED_ISO patch (included in -ck), because it can transparently exchanges SCHED_FIFO/RT with SCHED_ISO. A thread with SCHED_ISO can not outstarve the system because when using over 80% (default) cpu it's priority handling is revoked.
It also works fine on any system on that wine got the permission for SCHED_FIFO/RT, because when an App. behaves wrong (it's thread outstarves the rest of the system) a user can hit the magic-sysrq key combo for "disable SCHED_FIFO/RT for running processes". (I'm not sure if that magic-sysrq-key is available in mainline yet or only in -ck. Also note that on windows a base priority this high is able to outstarve the the system.)
About the "SCHED_FIFO/RT needs root"-problem: It does not. I think since Linux kernel 2.6.12 there is a new resource limit for realtime (think: ulimit). There are various ways to give wine an increased limit. Among them a suid helper called set_rlimits and using a up to date version of pam (newer version can set this limit). This is perhaps less critical than the process limit, which is I think per default on a Debian unlimited (think: fork bomb). This also seems to be _the_ solution for this problem in the (audio-)linux community.
So trying to use SCHED_FIFO and if it fails trying to use SCHED_ISO is safe for every system. (Not sure if that is the best order. A more complete patch would probably also take care of most of the other base priorities windows has by using SCHED_IDLE... SCHED_WINE anyone?) If the user chose to permit SCHED_FIFO/RT he is probably willing to risk needing to hit that magic-sysrq-key to disable it again. If he does not want to risk that he can use a kernel with SCHED_ISO.
Does this fit your requirement?
Jan
oh-la-la, very nice! This is a great idea, and we should work on it. And hopefully the SCHED_ISO patch get into the main kernel tree soon, cause the hourly openssl, or vmware, or running 7 simultaneous compiles that literally give the system the slashdot effect really get on my nerves....
Am Sonntag, 2. April 2006 15:23 schrieb Mike Hearn:
On Sun, 02 Apr 2006 03:49:39 +0200, Willie Sippel wrote:
Just tested Mike's patch with realtime-lsm. Running Wine as regular user now gives perfect audio with no stutter for every application I tried so far. So yes, realtime-lsm actually does the trick - me happy! ;)
Wonderful!
I load realtime-lsm with "gid=18 mlock=1 allcaps=1" (gid 18 is audio), and set wineserver to root:audio. Easy solution, great results!
I'm not sure it counts as easy. At least Fedora and SUSE already have an LSM module loaded, for SELinux and AppArmor respectively. Some solution based on making wineserver suid root might work but I didn't get anywhere when I played with that.
I might be wrong, but isn't a suid root winewrapper much more dangerous compared to the realtime-lsm solution? All realtime-lsm does is allowing mlock and realtime privileges for a given user or group, while a suid root wineserver would also have access to root-only files and device nodes, no?
Also, it seems realtime-lsm is part of the mm kernel, which means there's a chance it will end up in mainline in the near future, while SCHED_ISO will probably take longer or wont be included at all.
Anyway, a solution that tries to always use the best possible way seems to be the best option (try SCHED_FIFO, fallback to SCHED_ISO, fallback to default)...
I might be wrong, but isn't a suid root winewrapper much more dangerous compared to the realtime-lsm solution? All realtime-lsm does is allowing mlock and realtime privileges for a given user or group, while a suid root wineserver would also have access to root-only files and device nodes, no?
The idea would be to have it drop privs after acquiring CAP_SYS_NICE, or whatever it's called.
Alternatively have wineserver run as root (like the real kernel!) and do access checks on the client.
-
Alexandre Julliard -
Andreas Mohr -
Chris Morgan -
Jan Zerebecki -
Mike Hearn -
Peter Åstrand -
Segin -
Willie Sippel