On Wed, 05 Apr 2006 00:10:37 +1000, Con Kolivas wrote:
> Don't give up now as you will convince everyone else there is no solution and
> only your patch will make games work. Your attitude is defeatist because
> you're convinced that real time scheduling is your saviour. I'm trying to
> help you
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
> One problem that I am seeing is that there is no practical way to
> guarantee synchronization between the sound card hardware and the
> sound card thread. OSS doesn't support poll/select reliably in
> all drivers and the esd driver just writes
On Wednesday 05 April 2006 08:27, Willie Sippel wrote:
> Am Dienstag, 4. April 2006 16:46 schrieb Andreas Mohr:
> > Hi,
> >
> > On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > > > And this all should work perfectly well wi
Willie Sippel wrote:
No need for a full-blown game, I use this great free 5.9MB demo to test audio
on Wine:
http://www.pouet.net/prod.php?which=18359
Unbearable with regular Wine (kernel 2.6.13/ amd64, gentoo r5 patchset - can't
test with later kernels, as there's a problem with the SCSI-subsy
On Wednesday 05 April 2006 11:42, Segin wrote:
> Although I have ALSA in my kernel, I also use the OSS compatability, and
> on top of that, use more regulary than ALSA directly. I use OSS in Wine
> cause the WineALSA driver is fustrating, and wants odd settings
> (something about DirectSound emulat
On Wednesday 05 April 2006 21:47, Aneurin Price wrote:
> Con Kolivas wrote:
> > Is it kernel dependant? Does 2.6.11 for example exhibit the problem or
> > only recent kernels? Or has noone tried an older kernel like that?
> Just to reiterate since everybody seems to forget this part: The problem
>
Con Kolivas wrote:
Is it kernel dependant? Does 2.6.11 for example exhibit the problem or only
recent kernels? Or has noone tried an older kernel like that?
Cheers,
Con
Just to reiterate since everybody seems to forget this part: The problem
does *not* occur when using a 2.4 kernel. Addition
On 4/4/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Segin <[EMAIL PROTECTED]> wrote:
> > Although I have ALSA in my kernel, I also use the OSS compatability, and
> > on top of that, use more regulary than ALSA directly. I use OSS in Wine
> > cause the WineALSA driver is fustrating, and w
On 4/4/06, Segin <[EMAIL PROTECTED]> wrote:
> Although I have ALSA in my kernel, I also use the OSS compatability, and
> on top of that, use more regulary than ALSA directly. I use OSS in Wine
> cause the WineALSA driver is fustrating, and wants odd settings
> (something about DirectSound emulation
Robert Reif wrote:
Con Kolivas wrote:
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
One problem that I am seeing is that there is no practical way to
guarantee synchronization between the sound card hardware and the
sound card thread. OSS doesn't support poll/select reliably in
all
Con Kolivas wrote:
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
One problem that I am seeing is that there is no practical way to
guarantee synchronization between the sound card hardware and the
sound card thread. OSS doesn't support poll/select reliably in
all drivers and the esd
Am Mittwoch, 5. April 2006 00:57 schrieb Con Kolivas:
> On Wednesday 05 April 2006 08:27, Willie Sippel wrote:
> > Am Dienstag, 4. April 2006 16:46 schrieb Andreas Mohr:
> > > Hi,
> > >
> > > On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > > > On Wednesday 05 April 2006 00:34, Andr
Andreas Mohr wrote:
Hi,
On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
I think for now I shall just maintain this patch out of tree so savvy
users can apply it and get glitch-free audio. I have never been
convinced by t
Am Dienstag, 4. April 2006 16:46 schrieb Andreas Mohr:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > > And this all should work perfectly well with NON-soft-realtime
> > > scheduling, as clearly said before.
> >
Con Kolivas wrote:
>
> Ok. This is not a shot in the dark by the way because you mentioned pipes and
> I had a quick look at the wine sound code. I committed some changes to the
> cpu scheduler in 2.6.17-rc1 that change the way it views sleeping on pipes...
>
Works _much_ better with 2.6.17-rc
On 4/4/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
> > Audio playback and decoding should not really use much cpu.
>
> I'm not even sure we can control that. Some games seem to set up their
> own mixing threads and such (looking at the SDL Win32 code it calls
> SetThreadPriority itself).
>
Ah, I ha
On Wednesday 05 April 2006 00:46, Andreas Mohr wrote:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > > And this all should work perfectly well with NON-soft-realtime
> > > scheduling, as clearly said before.
> > >
On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > Is it kernel dependant? Does 2.6.11 for example exhibit the problem or
> > only recent kernels? Or has noone tried an older kernel like that?
>
> I think this has been a problem since time immemorial. Previous
> discussions like this one have
On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > > I think for now I shall just maintain this patch out of tree so savvy
> > > users can apply it and get glitch-fr
On Wednesday 05 April 2006 00:49, Mike Hearn wrote:
> >>> Don't give up now as you will convince everyone else there is no
> >>> solution and only your patch will make games work. Your attitude is
> >>> defeatist because you're convinced that real time scheduling is your
> >>> saviour.
>
> I don't
On Tuesday 04 April 2006 23:29, Mike Hearn wrote:
> > I know I didn't offer a solution, just standard rules for multithreaded
> > application writing. The fact that wine is a compatibility layer rather
> > than its own application is most of your problem. Is there no way wine
> > could have an audi
On Tuesday 04 April 2006 23:46, Mike Hearn wrote:
> > By infinite loop I assume you mean it is sleeping, not burning cpu... But
> > anyway, is this a separate thread or part of a monolithic "wine"?
>
> Right, it blocks on a message pipe. It's a separate thread.
>
> > I think fragile is too harsh a
On Tuesday 04 April 2006 22:42, Mike Hearn wrote:
> > What strikes me is that people are very happy to think that the kernel is
> > going to fix this problem. I have to tell you there will be no more
> > infrastructure put into the kernel anytime soon to help you here.
>
> I'm confused about this p
Hmm, difficult :-\
I don't have any game candidate here, and frankly I don't even have a current
Wine install...
Getting a new Wine is easier than a new kernel :) The game I played with
is a demo, available here:
ftp://ftp.infogrames.net/demos/imperiumgalactica2/ig2_english.zip
It's a rea
Hi,
On Tue, Apr 04, 2006 at 03:49:56PM +0100, Mike Hearn wrote:
> So in this case either the CPU time goes way high when the 3D scene
> first appears, or maybe my 3D driver (nvidia) is not allowing
> pre-emption enough.
nvidia... nvidia... Hrmmm... might this just be caused by the recent
annoyi
Don't give up now as you will convince everyone else there is no solution
and only your patch will make games work. Your attitude is defeatist
because you're convinced that real time scheduling is your saviour.
I don't want to do that! If there are other [robust] solutions I'm all
ears. The pa
Hi,
On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > And this all should work perfectly well with NON-soft-realtime scheduling,
> > as clearly said before.
> > Well, in theory, at least...
>
> Andi just out of interest, how d
Hi,
On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
> On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > I think for now I shall just maintain this patch out of tree so savvy
> > users can apply it and get glitch-free audio. I have never been
> > convinced by this sacred devotion
Is it kernel dependant? Does 2.6.11 for example exhibit the problem or only
recent kernels? Or has noone tried an older kernel like that?
I think this has been a problem since time immemorial. Previous
discussions like this one have always gone around in the same circle -
it needs root what do
By infinite loop I assume you mean it is sleeping, not burning cpu... But
anyway, is this a separate thread or part of a monolithic "wine"?
Right, it blocks on a message pipe. It's a separate thread.
I think fragile is too harsh a way to describe it. You're not after 100%
realtime guarantee, j
I know I didn't offer a solution, just standard rules for multithreaded
application writing. The fact that wine is a compatibility layer rather than
its own application is most of your problem. Is there no way wine could have
an audio thread that does nothing but the compatibility component betw
What strikes me is that people are very happy to think that the kernel is
going to fix this problem. I have to tell you there will be no more
infrastructure put into the kernel anytime soon to help you here.
I'm confused about this point. You say the kernel won't be changing
anytime soon - do
On Tue, 4 Apr 2006 01:47 am, Andreas Mohr wrote:
> Hi,
>
> [sneaked in another CC, JFYI ;]
Oh hi! This is the first time this thread has been brought to my attention.
> On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote:
> > And even then, SCHED_ISO is a long way off and may never be merg
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?
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 actu
Hi,
[sneaked in another CC, JFYI ;]
On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote:
> And even then, SCHED_ISO is a long way off and may never be merged.
> Waiting for it wouldn't be helping users today, which is a bad thing IMHO.
I don't think SCHED_ISO is necessarily a long way of
More on topic, does this simply change Wine's priority or does it act on
a per-thread level? Most of the issues I've seen have been caused by the
audio thread being starved by the others, and is often semi-solved by
running Wine at nice 19
The latter. I did try renicing Wine first, but no joy.
Hi,
On Mon, Apr 03, 2006 at 04:04:05PM +0100, Aneurin Price wrote:
> Anyway, surely the `best' way would be for the kernel to support
> user-level `real-time' priorities like the ck kernels. Anybody know why
> they don't like the idea of that kind of thing?
Con Kolivas is doing some very active
Mike Hearn wrote:
I'm not convinced this is true. At least some (maybe most or all) of
the games showing this problem work just fine if true OSS (ie. not
ALSA-emulated OSS) is used as the sound driver. WoW and StarCraft
spring to mind immediately. Plus apparently they work in Cedega
without ne
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
i
Jan Zerebecki wrote:
On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
Mike Hearn <[EMAIL PROTECTED]> 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 s
On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
> Mike Hearn <[EMAIL PROTECTED]> 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 sui
Alexandre Julliard wrote:
Mike Hearn <[EMAIL PROTECTED]> 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 anywhe
Mike Hearn <[EMAIL PROTECTED]> 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
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
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-r
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.
A
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 hel
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
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 driv
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'
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 <[EMAIL PROTECTED]> wrote:
> > Until it crashes your box of course...
>
> If a Windows program has a habi
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
ga
Mike Hearn <[EMAIL PROTECTED]> 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,
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
:
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 adop
56 matches
Mail list logo