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
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.
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 emulation
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
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 to
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 with
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 merged.
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 -
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
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,
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
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 to
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 does
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
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 point.
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 audio
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 way to
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
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.
Well, in
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
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, Andreas Mohr 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 drivers and the esd
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
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 -- I
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 wants odd
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
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
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
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
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
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?
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
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
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
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
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
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
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.
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
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
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
:)
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, or give
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
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 habit of
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
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
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
47 matches
Mail list logo
