On Wed, May 26, 2010 at 12:32 AM, wrote:

I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.

I don't know what you are saying. Just use nvidia. or nv or vesafb. Or if none of the drivers suits you, just use a different brand. Or if none of linux graphic drivers suits you, then use a different os.

On 25 May 2010 16:32, wrote:

On Mon, May 24, 2010 at 11:42:54PM +0200, Xavier Chantry wrote:

...

Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ?

Would that be possible at all, given

 24.3.2010 posted by xavier  Merge of 2.6.34-rc2.  On Monday, nouveau git tree went straight from 2.6.32 to 2.6.34-rc2.  One backlight API change in 2.6.34-rc2 breaks compatibility with older  kernels (< 2.6.34-rc2), so people doing out-of-tree builds will have to  update their kernel to rc2. Alternatively, you could try to revert the  backlight commit.

The last thing I want is to get entangled in a recursive 'update to the latest' game.

Um, one of the packages he suggested you build is a GIT kernel with nouveau merged in, which will work fine.

I tried the inverse today - downgrading nouveau to the version used on the machines that do work. Same problem, the older version wants a kernel < 2.6.33, and gods knows where things will end if I go that route.

This is not about hacking and having fun with bleeding edge versions. Apart from the machine that doesn't work (and I don't expect anything more than what all distros since a year or two have been able to provide OOTB), there's 9000 Euro of audio hardware sitting idle.

I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.

The binary nvidia driver? Also, I seriously doubt that the devs would have let this go to extra if they personally experienced this problem. And, nouveau is still in development, so you get what you sign up for, to some extent.

Ciao,

--

FA

O tu, che porte, correndo si ? E guerra e morte !

-- Tavian Barnes

On 26 May 2010 08:56, wrote:

On Tue, May 25, 2010 at 05:33:36PM -0600, Tavian Barnes wrote:

...

The binary nvidia driver?

Has latency problems as well, which is why people doing serious audio are using nv.

If someone can tell me how to get it installed on current Arch I'd be most happy to use nv.

...

Also, I seriously doubt that the devs would have let this go to extra if they personally experienced this problem.  And, nouveau is still in development, so you get what you sign up for, to some extent.

True, and that it not a real problem. But as long as nouveau is still in this state, it would be wise to provide an alternative. AFAICS, you just can't use nv anymore with current Arch.

Yeah you can. nv isn't a kernel module though, it's just an Xorg driver, still using UMS. To use it, 1) Blacklist nouveau and nvidia 2) Install xf86-video-nv 3) Set Driver to "nv" in xorg.conf And, even if nv doesn't work for you, there's always xf86-video-vesa and xf86-video-fbdev.

Ciao,

-- FA

O tu, che porte, correndo si ? E guerra e morte !

-- Tavian Barnes

Excerpts from fons's message of 2010-05-26 22:50:43 +0200:

On Wed, May 26, 2010 at 09:22:15AM -0600, Tavian Barnes wrote:

...

Yeah you can. nv isn't a kernel module though, it's just an Xorg driver, still using UMS. To use it,

1) Blacklist nouveau and nvidia 2) Install xf86-video-nv 3) Set Driver to "nv" in xorg.conf

And, even if nv doesn't work for you, there's always xf86-video-vesa and xf86-video-fbdev.

Many thanks !

I did as you suggested. Booting the default image failed with what looked like a very long backtrace and froze the machine.

But booting fallback worked, and after an mkinitcpio also the default worked.

Result: rock-stable audio, and the display is a fast as it needs to be.

Again many thanks, finally I can start using this system.

BTW, what is the official advantage of KMS ? Having RL 3 and ttys that do not depend on a video driver seems like a good thing (TM) to me.

Ciao,

Glad it works for you now. KMS was advertised mainly with he following features: - TTY in native resolution and hence nicer to look at - shorter delay when switching from X to TTY -- Regards, Philipp ----- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

Excerpts from fons's message of 2010-05-26 00:32:22 +0200:

On Mon, May 24, 2010 at 11:42:54PM +0200, Xavier Chantry wrote:

...

Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ?

Would that be possible at all, given

24.3.2010 posted by xavier Merge of 2.6.34-rc2. On Monday, nouveau git tree went straight from 2.6.32 to 2.6.34-rc2. One backlight API change in 2.6.34-rc2 breaks compatibility with older kernels (< 2.6.34-rc2), so people doing out-of-tree builds will have to update their kernel to rc2. Alternatively, you could try to revert the backlight commit.

The last thing I want is to get entangled in a recursive 'update to the latest' game.

I tried the inverse today - downgrading nouveau to the version used on the machines that do work. Same problem, the older version wants a kernel < 2.6.33, and gods knows where things will end if I go that route.

This is not about hacking and having fun with bleeding edge versions. Apart from the machine that doesn't work (and I don't expect anything more than what all distros since a year or two have been able to provide OOTB), there's 9000 Euro of audio hardware sitting idle.

I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.

Ciao,

As someone else suggested, I'd try the nv driver. It's generally worse than nouveau in its graphics performance, but it's usable. It's what has been used for years by those who didn't want to use the proprietary nvidia driver. It used to work o.k. for me with regards to audio, but I never used very low frame settings (never under 128). The proprietary driver is also an option but it used to perform worse with regards to audio than nv. Mileage seems to vary with every version. The other option I see is trying to duplicate the setup you have on your other machines. The packages should be in pacmans cache. There may be an automatic or semi-automatic way to do this. Then I'd test new kernel/nouveau versions and see whether the situation improves. Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all. -- Regards, Philipp ----- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

On Wed, May 26, 2010 at 09:54:26AM +0200, Xavier Chantry wrote:

On Wed, May 26, 2010 at 2:08 AM, Philipp Überbacher wrote:

...

Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all.

It's definitely not their primary focus. But if you open a bug report saying "that commit greatly increased latency" and you can prove it, you can be sure they will do something about it.

I will. But my first concern ATM is to get this system in a usable state - that's what the customer pays me for. On of the many things I tried before even posting was to use the nv driver. Modified the xorg.conf, but for some reason, the system goes on using nouveau regardless. ** Is it still possible to use nv on today's Arch ? ** I've used nv for years without any problem. The reason to prefer it over nvidia was not ideological - nvidia has latency problems as well, and I never needed 3D acceleration. Looking at the xrun statistics in function of audio period size, it looks like current nouveau is blocking audio (either by dis- abling interrupts, or by locking a shared HW resource) for about 3-4 ms. *No* driver today should ever do that - it's really late 1990's performance.

The work to provide good, detailed, and useful bug reports is in user's hands, not developers'. When the users don't do their homework, regressions remain.

Agreed. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Wed, May 26, 2010 at 11:26:58PM +0200, Xavier Chantry wrote:

As I said, there are some people who are willing to help in that area. But without people like you reporting and testing, it's never going to happen. We need audio guys and graphics/drivers guys allocating some times to work together and resolve the issues.

There was at least one nouveau developer trying to help out : http://lists.freedesktop.org/archives/nouveau/2010-February/004981.html But the reporter just disappeared.

The name (Adrian Knoth) rings a bell, he's probably on one of Linux Audio lists. And if he's using firewire audio he must be one of the 'brave ones' - it's not obvious at all ATM. So Maarten Maathuis looks like the one to get in contact with.

And just a reminder that these people help/work for free in their limited spare time :)

Most of us who write and contribute things are in that situation... Isn't there any contact/overlap between the nv and nouveau teams ? The nv devs got this right (it also took them some time IIRC), but that shows it's possible. As you have probably been reading, meanwhile I've been able to get nv in place instead of nouveau, and things just work. The 'blacklist' trick should be documented somewhere - it's obvious once you know it but it surely didn't pop up by itself. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !