13 Feb
2013
13 Feb
'13
8:58 p.m.
I've installed Ubuntu Studio 13.04. It has a real time version
of the latest kernel and I quite like the XFCE desktop, although
I'm more used to KDE. It boots from Grub in about seven seconds,
which is remarkable.
But I use one installation for all and I really need proprietary
Nvidia drivers. Preferably version 310. I've tried installing
'nvidia-current' which provides v304, but doesn't work. An 'apport'
problem is mentioned in the (Synaptic) details during install and
the 'Nvidia Settings' widget reports no working driver installed
and to try running 'sudo nvidia-config' (or something like that)
which I tried. Even tried copying a known good xorg.conf from my
currently working KDE (12.04). On a previous attempt I tried most
variations of 310 and something from an xorg-edgers ppa.
I've had similar problems before, requiring various blacklisting
of Nouveau and certain framebuffer drivers, but before I try that;
is there some other possible reason why ubuntu-studio 13.04 or
XFCE isn't likely to work with (closed) nvidia drivers?
Anyone got it working with 310.n driver who could provide hints?
Thanks.
--
John.
13 Feb
13 Feb
9:41 p.m.
On 02/13/2013 10:58 AM, John Murphy wrote:
I've installed Ubuntu Studio 13.04. It has a real
time version
of the latest kernel and I quite like the XFCE desktop, although
I'm more used to KDE. It boots from Grub in about seven seconds,
which is remarkable.
But I use one installation for all and I really need proprietary
Nvidia drivers. Preferably version 310. I've tried installing
'nvidia-current' which provides v304, but doesn't work. An 'apport'
problem is mentioned in the (Synaptic) details during install and
the 'Nvidia Settings' widget reports no working driver installed
and to try running 'sudo nvidia-config' (or something like that)
which I tried. Even tried copying a known good xorg.conf from my
currently working KDE (12.04). On a previous attempt I tried most
variations of 310 and something from an xorg-edgers ppa.
Perhaps the closed driver needs to be installed when X is not running?
Try from a text login?
I've had similar problems before, requiring
various blacklisting
of Nouveau and certain framebuffer drivers, but before I try that;
is there some other possible reason why ubuntu-studio 13.04 or
XFCE isn't likely to work with (closed) nvidia drivers?
XFCE shouldn't care a bit about which video driver you use; it's just
using X. I've used XFCE on closed NVidia drivers (not the version you're
talking about) without any problems. Installed them using Synaptic with
no problems.
Can't answer for Ubuntu 13, though. Ubuntu's Unity interface tries to do
what I consider fancy stuff for the desktop UI, so it might be more
sensitive to drivers. (Like KDE4 in that area, I think.)
But I think if you can't even get X to run the driver in the first place
(boot to a text login, login and run "startx"), you haven't even gotten
to the point where XFCE or the Ubuntu UI is trying to use it.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://clanjones.org/david/
http://dancing-treefrog.deviantart.com/
14 Feb
14 Feb
1:54 a.m.
On Wed, 13 Feb 2013 11:41:06 -1000, david wrote:
That's what I would have expected. Possibly the 'studio' parts are
causing the problem then (in that I probably don't have the right
linux-headers or something similar).
On 02/13/2013 10:58 AM, John Murphy wrote:
A good suggestion, thank you, but no difference unfortunately.
I stopped the display manager (lightdm) from a virtual terminal
and tried 'sudo apt-get install nvidia-310-dev'. It worked, but
still no working driver according to nvidia-settings. After running
nvidia-config I'm limited to 640x480, which doesn't help.
I've installed Ubuntu Studio 13.04. It has a
real time version
of the latest kernel and I quite like the XFCE desktop, although
I'm more used to KDE. It boots from Grub in about seven seconds,
which is remarkable.
But I use one installation for all and I really need proprietary
Nvidia drivers. Preferably version 310. I've tried installing
'nvidia-current' which provides v304, but doesn't work. An 'apport'
problem is mentioned in the (Synaptic) details during install and
the 'Nvidia Settings' widget reports no working driver installed
and to try running 'sudo nvidia-config' (or something like that)
which I tried. Even tried copying a known good xorg.conf from my
currently working KDE (12.04). On a previous attempt I tried most
variations of 310 and something from an xorg-edgers ppa.
Perhaps the closed driver needs to be installed when X is not running?
Try from a text login? I've had
similar problems before, requiring various blacklisting
of Nouveau and certain framebuffer drivers, but before I try that;
is there some other possible reason why ubuntu-studio 13.04 or
XFCE isn't likely to work with (closed) nvidia drivers?
XFCE shouldn't care a bit about which video driver you use; it's just
using X. I've used XFCE on closed NVidia drivers (not the version you're
talking about) without any problems. Installed them using Synaptic with
no problems. Can't answer for Ubuntu 13, though. Ubuntu's
Unity interface tries to do
what I consider fancy stuff for the desktop UI, so it might be more
sensitive to drivers. (Like KDE4 in that area, I think.)
I tried Ubuntu 13.04 between attempts with the studio version. It would
only boot to a rescue 'low graphics' mode, which turned out to be just
a login prompt, but I was able to update and then install nvidia-current
OK on that and it worked fine on the next reboot.
But I think if you can't even get X to run the
driver in the first place
(boot to a text login, login and run "startx"), you haven't even gotten
to the point where XFCE or the Ubuntu UI is trying to use it.
Just downloaded a daily build of Xubuntu 13.04. I'll try starting
from there. All of these Raring-Ringtail installs are a bit awkward
for me, as there's a bug which means I have to disconnect all HDDs
bar the one on which I'm going to install. :|
Thanks.
--
2:23 a.m.
On Wed, February 13, 2013 5:54 pm, John Murphy wrote:
That's what I would have expected. Possibly the
'studio' parts are
causing the problem then (in that I probably don't have the right
linux-headers or something similar).
Studio is xubuntu with extra apps. The kernel is the same as the generic
kernel (used for all the other buntus) with one different parameter for
lowlatency. I think you can even take the generic kernel and add the param
at boot time. I could be wrong, we did try that at one time... just pre
12.04 ish so the generic may have changed, zequence in the #ubuntustudio
IRC channel should know what the differences are these days. An easy test
though is just to install the generic kernel on top of studio. You would
then be able to boot either one.
--
Len Ovens
www.OvenWerks.net
4:59 a.m.
On Wed, 13 Feb 2013 18:23:00 -0800, Len Ovens wrote:
On Wed, February 13, 2013 5:54 pm, John Murphy wrote:
Well I just tried an Xubuntu 13.04 'daily' build and, similarly to Ubuntu,
I got a login prompt without X running and installed nvidia-310-dev, which
works OK. It takes ages, compared to Studio, to boot from Grub to login
though, so there's some magic under the hood of the Studio version I think.
The glx-alternative-nvidia package I mentioned was a red herring. (Sorry
if that doesn't translate well Ralph - a false lead. :)) It gets marked
as broken in Xubuntu too.
I'll try re-installing Studio, but only boot to a rescue prompt next.
It's always so hard to get a run level with everything <X on *buntu.
Thanks.
--
That's what I would have expected. Possibly
the 'studio' parts are
causing the problem then (in that I probably don't have the right
linux-headers or something similar).
Studio is xubuntu with extra apps. The kernel is the same as the generic
kernel (used for all the other buntus) with one different parameter for
lowlatency. I think you can even take the generic kernel and add the param
at boot time. I could be wrong, we did try that at one time... just pre
12.04 ish so the generic may have changed, zequence in the #ubuntustudio
IRC channel should know what the differences are these days. An easy test
though is just to install the generic kernel on top of studio. You would
then be able to boot either one.
5:13 a.m.
On Wed, February 13, 2013 8:59 pm, John Murphy wrote:
On Wed, 13 Feb 2013 18:23:00 -0800, Len Ovens wrote:
Ubuntustudio took xubuntu as it's start at 11.10 and probably hasn't
merged in any new stuff xubuntu has since then. So there may just be less
stuff in Studio.
--
Len Ovens
www.OvenWerks.net
On Wed, February 13, 2013 5:54 pm, John Murphy wrote:
Well I just tried an Xubuntu 13.04 'daily' build and, similarly to Ubuntu,
I got a login prompt without X running and installed nvidia-310-dev, which
works OK. It takes ages, compared to Studio, to boot from Grub to login
though, so there's some magic under the hood of the Studio version I
think. That's what I would have expected. Possibly
the 'studio' parts are
causing the problem then (in that I probably don't have the right
linux-headers or something similar).
Studio is xubuntu with extra apps. The kernel is the same as the generic
kernel (used for all the other buntus) with one different parameter for
lowlatency. I think you can even take the generic kernel and add the
param
at boot time. I could be wrong, we did try that at one time... just pre
12.04 ish so the generic may have changed, zequence in the #ubuntustudio
IRC channel should know what the differences are these days. An easy
test
though is just to install the generic kernel on top of studio. You would
then be able to boot either one.
4:52 p.m.
On Wed, 13 Feb 2013 21:12:57 -0800, Len Ovens wrote:
On Wed, February 13, 2013 8:59 pm, John Murphy wrote:
It certainly makes for a very slick distro and one I'll probably use
until KDE5, if not forever!
Tried one more time with the low-latency 3.8.0.6 kernel, but no go.
As soon as I rebooted after installing Generic, nvidia-310-dev was
up and running, which is great. Means I'll be able to compare the
performance of the two kernel types, which could be useful.
Thanks.
--
Well I just tried an Xubuntu 13.04 'daily' build and, similarly to Ubuntu,
I got a login prompt without X running and installed nvidia-310-dev, which
works OK. It takes ages, compared to Studio, to boot from Grub to login
though, so there's some magic under the hood of the Studio version I
think.
Ubuntustudio took xubuntu as it's start at 11.10 and probably hasn't
merged in any new stuff xubuntu has since then. So there may just be less
stuff in Studio. 
5:06 p.m.
On Thursday 14 February 2013 11:54:38 John Murphy did opine:
On Wed, 13 Feb 2013 21:12:57 -0800, Len Ovens wrote:
John, in my experience, you are shooting yourself about kneecap high by
running the nvidia driver. It gets part of its performance by locking out
the interrupts, for extended periods of time. For an app that needs true
real time, such as linuxcnc, a 5 microsecond base thread jitter in its
timing, has been logged as creating latency jitters in the 200 millisecond
range. Even for the more forgiving servomotor stuff its not good, and its
totally intolerable for steppers which need a steady heartbeat to move at
more than creep speeds.
The nouveau driver gained some support for the 3d stuff recently, and it
should be checked out to see if it makes the xruns and such worse or
better. As a final check to see if the video is an xrun causer, try the
vesa driver, there have been times when I was forced to use it on my
machine tool (cnc machinery) controllers. Poor display of course, but the
machine worked great.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Today is National Existential Ennui Awareness Day.
I was taught to respect my elders, but its getting
harder and harder to find any...
On Wed, February 13, 2013 8:59 pm, John Murphy
wrote:
It certainly makes for a very slick distro and one I'll probably use
until KDE5, if not forever!
Tried one more time with the low-latency 3.8.0.6 kernel, but no go.
As soon as I rebooted after installing Generic, nvidia-310-dev was
up and running, which is great. Means I'll be able to compare the
performance of the two kernel types, which could be useful.
Thanks. Well I just tried an Xubuntu 13.04
'daily' build and, similarly to
Ubuntu, I got a login prompt without X running and installed
nvidia-310-dev, which works OK. It takes ages, compared to Studio,
to boot from Grub to login though, so there's some magic under the
hood of the Studio version I think.
Ubuntustudio took xubuntu as it's start at 11.10 and probably hasn't
merged in any new stuff xubuntu has since then. So there may just be
less stuff in Studio.
7:10 p.m.
On Thursday 14 February 2013 13:35:26 Ralf Mardorf did opine:
On Thu, 2013-02-14 at 12:06 -0500, Gene Heskett
wrote:
Possibly not. What I am pointing out is that unlike all the fussing about
it, xruns and all, and invoking all sorts of black magic speels to control
it, working virtually blind, on LAU/LAD, we were forced to write test
utilities that quantified the results in an easy to understand format. The
net result being that we have a pretty good idea of the causes of the
failures when the figures do blow up.
Certain motherboards are pure junk, and a few are truly outstanding given
their relatively meager specs on the box they ship in. The intel Atom dual
core boards being a case in point. The now almost out of the pipeline
D525MW board, with a gig of ram and onboard intel video being an excellent
example, turning in results consistently under 7 microseconds for a
base_thread jitter when running the base IO thread at a 25 microsecond
repeat rate. The parent servo_thread, running every millisecond, has
similar performance on this board. Testwise while carving metal, I have
run the servo_thread at 2 kilohertz with even better results, and I intend
to raise that a kilohertz at a time until I run out of cpu because it seems
to reduce the detected noise in a quadrature encoded spindle speed control
as it goes up, effectively reducing the quantization errors in such a
software only servo control.
This motherboard, an ASUS M2N_SLI Deluxe is relatively poor despite a quad
core phenom running at 2.1 ghz with 4G of dram.
It is currently reporting the 1ms servo thread as having 15 microseconds of
timing jitter, and nearly 45 microseconds of jitter for a 25 microsecond IO
thread, and the machine is quite obviously 'pegged out'.
This base thread is probably not of interest to you audio people, but many
motherboards will have far worse servo_thread timing dependabilities simply
because the context switch takes too much time. This is of course on an
RTAI patched kernel, but we are about to move to the xenomi patchset, as
its easier to do, is all user-space, and actually working at least as well
as the RTAI patches.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
There comes a time in the affairs of a man when he has to take the bull
by the tail and face the situation.
-- W. C. Fields
I was taught to respect my elders, but its getting
harder and harder to find any...
5 microsecond base thread jitter in its timing
I agree that the nvidia driver could cause issues, but 5 ms jitter? This
perhaps is an issue for the RTAI, but I guess not for the audio RT
kernels.
7:22 p.m.
> On Thu, 2013-02-14 at 12:06 -0500, Gene Heskett
wrote:
> > 5 microsecond
I'll read your mail tomorrow, but I noticed already my mistake. I read
"milliseconds" instead of "microsecond" ;). It seemed to me
impossible
that (without knowing how it is done) the driver will cause 5 ms thread
jitter, but I can imagine that 5 µs are possible. ;)
7:29 p.m.
On Thursday 14 February 2013 14:28:43 Ralf Mardorf did opine:
No Ralf, in Re nvidia, milliseconds was the correct nomenclature, as in
100's of milliseconds.
> On Thu,
2013-02-14 at 12:06 -0500, Gene Heskett wrote:
> > 5 microsecond
I'll read your mail tomorrow, but I noticed already my mistake. I read
"milliseconds" instead of "microsecond" ;). It seemed to me
impossible
that (without knowing how it is done) the driver will cause 5 ms thread
jitter, but I can imagine that 5 µs are possible. ;) _______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Idleness is the holiday of fools.
I was taught to respect my elders, but its getting
harder and harder to find any...
11:03 p.m.
On Thu, February 14, 2013 11:09 am, Gene Heskett wrote:
On Thursday 14 February 2013 13:35:26 Ralf Mardorf did
opine:
Have you tested hyperthreading enabled or not? I was quite surprised at
the difference on my old P4 as I was able to run my Audio IF at half the
latency (32frames instead of 64) with hyperthreading disabled. I have yet
to try my atom based netbook this way. I guess linux thinks they are two
cores and so is not picky about what it pairs with rt thread, which can
end up waiting for CPU time.
--
Len Ovens
www.OvenWerks.net
On Thu, 2013-02-14 at 12:06 -0500, Gene Heskett
wrote:
Possibly not. What I am pointing out is that unlike all the fussing about
it, xruns and all, and invoking all sorts of black magic speels to control
it, working virtually blind, on LAU/LAD, we were forced to write test
utilities that quantified the results in an easy to understand format.
The
net result being that we have a pretty good idea of the causes of the
failures when the figures do blow up.
Certain motherboards are pure junk, and a few are truly outstanding given
their relatively meager specs on the box they ship in. The intel Atom
dual
core boards being a case in point. The now almost out of the pipeline
D525MW board, with a gig of ram and onboard intel video being an excellent
example, turning in results consistently under 7 microseconds for a
base_thread jitter when running the base IO thread at a 25 microsecond 5 microsecond base thread jitter in its timing
I agree that the nvidia driver could cause issues, but 5 ms jitter? This
perhaps is an issue for the RTAI, but I guess not for the audio RT
kernels.
15 Feb
15 Feb
3:02 a.m.
New subject: Gmorgan0.58 on Fedora without Nvidia drivers
Gmorgan0.58 sequencer (free on sourceforge) runs fine on Ubuntu 12.04,
but not on Fedora 17.
Using gmorgan0.58 with Fedora 17 and ccrma repository,
the sequencer does not keep time. Comment out the
FLTK redraw statement and it recovers, ( but it
no longer scrolls.)
I asked on the FLTK forum why this might be, and
the suggestion came back that forcing the install of
Nvidia drivers would likely solve the problem.
Is there a Fedora user willing to verify this ?
16 Feb
16 Feb
2:17 p.m.
On Thu, 14 Feb 2013 12:06:06 -0500, Gene Heskett wrote:
On Thursday 14 February 2013 11:54:38 John Murphy did
opine:
Thanks for that Gene. Really interesting. I tried searching the net
for anything which would provide more information, and about all I could
quickly find was where older Linux kernels used 'edge detection' for
interrupts as opposed to 'level detection'. I see LinuxCNC still uses
either 2.4 or 2.6 kernels, which are the ones mentioned in the article.
Maybe things have improved with all the fine work which has gone into
the kernel since then. In Linus I trust. ;)
On Wed, 13 Feb 2013 21:12:57 -0800, Len Ovens
wrote:
John, in my experience, you are shooting yourself about kneecap high by
running the nvidia driver. It gets part of its performance by locking out
the interrupts, for extended periods of time. For an app that needs true
real time, such as linuxcnc, a 5 microsecond base thread jitter in its
timing, has been logged as creating latency jitters in the 200 millisecond
range. Even for the more forgiving servomotor stuff its not good, and its
totally intolerable for steppers which need a steady heartbeat to move at
more than creep speeds. On Wed, February 13, 2013 8:59 pm, John Murphy
wrote:
It certainly makes for a very slick distro and one I'll probably use
until KDE5, if not forever!
Tried one more time with the low-latency 3.8.0.6 kernel, but no go.
As soon as I rebooted after installing Generic, nvidia-310-dev was
up and running, which is great. Means I'll be able to compare the
performance of the two kernel types, which could be useful.
Thanks. Well I just tried an Xubuntu 13.04
'daily' build and, similarly to
Ubuntu, I got a login prompt without X running and installed
nvidia-310-dev, which works OK. It takes ages, compared to Studio,
to boot from Grub to login though, so there's some magic under the
hood of the Studio version I think.
Ubuntustudio took xubuntu as it's start at 11.10 and probably hasn't
merged in any new stuff xubuntu has since then. So there may just be
less stuff in Studio. The nouveau driver gained some support for the 3d
stuff recently, and it
should be checked out to see if it makes the xruns and such worse or
better. As a final check to see if the video is an xrun causer, try the
vesa driver, there have been times when I was forced to use it on my
machine tool (cnc machinery) controllers. Poor display of course, but the
machine worked great.
It will be easy enough to compare as the low-latency kernel can't
work as is with the Nvidia driver, so I'll be able to switch between
Generic + Nvidia and low-latency + Nouveau. I may have already used
the Vesa driver. I was limited to 640x480 at one stage. :)
--
14 Feb
14 Feb
5:37 p.m.
On Thu, 14 Feb 2013 04:59:45 +0000, John Murphy wrote:
It's always so hard to get a run level with everything <X on *buntu.
No problem with the 'rescue' boot option of US 13.04. I just used
the (ncurses display) options to 'start networking' and 'drop to
root prompt'. Then 'apt-get update' etc.
One thing which did bite me was that booting the install media
in 'UEFI' mode, if the option is available, seems to lead to
an un-bootable system and:
error: file '/boot/grub/i386-pc/normal.mod' not found.
grub rescue>
('Least I think that's what caused it.)
--
John.
8:22 a.m.
On Wed, 2013-02-13 at 18:23 -0800, Len Ovens wrote:
I think you can even take the generic kernel and add
the param
at boot time.
It's a good idea to test the graphics driver with the generic kernel.
For test purpose it might be good to remove the lowlatency kernel and
for the generic kernel _not_ to set threadirqs or what ever parameter is
meant.
FWIW 3D screensavers should work with nouveau too, I suspect that only a
few games need a proprietary driver.
I'm a Ubuntu Studio user too and removed my NVIDA graphics from my
computer, using the integrated ATI now, with the FLOSS driver. Something
like Google Earth is as fast as with the NVIDIA proprietary and with
nouveau, but ATI at the moment does cause less (= no) pain on my
machine, but even NVIDIA doesn't cause serious pain. NVIDIA proprietary
driver support usually is better than ATI proprietary driver support for
Linux. For my ATI there is no proprietary driver that does work with
current versions of X.
I'm not a gamer. Perhaps it's better to have separated installs, one for
games, the other for audio-realtime.
5:12 p.m.
On Thu, 14 Feb 2013 09:22:13 +0100, Ralf Mardorf wrote:
On Wed, 2013-02-13 at 18:23 -0800, Len Ovens wrote:
Yes, that worked Nvidia 310.32 installed and working fine on Generic.
I think you can even take the generic kernel and
add the param
at boot time.
It's a good idea to test the graphics driver with the generic kernel.
For test purpose it might be good to remove the lowlatency kernel and
for the generic kernel _not_ to set threadirqs or what ever parameter is
meant. FWIW 3D screensavers should work with nouveau too, I
suspect that only a
few games need a proprietary driver.
I'll be able to compare results between the Nouveau and proprietary
drivers. Doesn't mean much I'm sure, but glxgears managed 85fps with
Nouveau and 3,520fps with 310.32 (GeForce GTX 560 Ti) :)
I'm a Ubuntu Studio user too and removed my NVIDA
graphics from my
computer, using the integrated ATI now, with the FLOSS driver. Something
like Google Earth is as fast as with the NVIDIA proprietary and with
nouveau, but ATI at the moment does cause less (= no) pain on my
machine, but even NVIDIA doesn't cause serious pain. NVIDIA proprietary
driver support usually is better than ATI proprietary driver support for
Linux. For my ATI there is no proprietary driver that does work with
current versions of X.
Mmm. Google Earth. I must get on installing and configuring.
I'm not a gamer. Perhaps it's better to have
separated installs, one for
games, the other for audio-realtime.
It may well come to that. Boot is so amazingly fast, it would hardly
matter if I do need to go that way, but I prefer everything working
well on one kernel if possible.
Thanks again.
--
15 Feb
15 Feb
9:43 a.m.
On Thu, 14 Feb 2013 02:54:13 +0100, John Murphy
<rosegardener(a)freeode.co.uk> wrote:
A good suggestion, thank you, but no difference
unfortunately.
I stopped the display manager (lightdm) from a virtual terminal
and tried 'sudo apt-get install nvidia-310-dev'. It worked, but
still no working driver according to nvidia-settings. After running
nvidia-config I'm limited to 640x480, which doesn't help.
That's what I would have expected. Possibly the 'studio' parts are
causing the problem then (in that I probably don't have the right
linux-headers or something similar).
First, ask yourself, if you really need proprietary drivers (and I can't
really speak for the reasons to why you should or should not need them).
The free drivers have in fact become more or less fully functional, so you
might not need the proprietary ones. I was even using the free drivers
playing steam games recently (all though, not problem free).
This is not a desktop problem at all. So, it doesn't matter if you're
using XFCE, KDE
or Gnome. The only two things that are involved is the kernel (and
associated libraries and tools), and the driver.
to build the nvidia kernel module you need the headers for the kernel you
are running, but that should take care of itself when you install
something like nvidia-304. Make sure you are running the kernel you are
intending to build the module for, before proceeding.
Also, move your xorg.conf, if you have one.
There's the method of using Software Sources (software-properties-gtk),
under the tab "Additional Drivers", where you can select a number of
options.
You get the same result when installing from the terminal. All I did was
"sudo apt-get install nvidia-304". This was on "3.8.0-6-lowlatency".
There's always the chance that previous kernels did not work well with the
proprietary drivers.
I've
had similar problems before, requiring various blacklisting
of Nouveau and certain framebuffer drivers, but before I try that;
is there some other possible reason why ubuntu-studio 13.04 or
XFCE isn't likely to work with (closed) nvidia drivers?
XFCE shouldn't care a bit about which video driver you use; it's just
using X. I've used XFCE on closed NVidia drivers (not the version you're
talking about) without any problems. Installed them using Synaptic with
no problems.
16 Feb
16 Feb
2:43 p.m.
On Fri, 15 Feb 2013 10:43:50 +0100, Kaj Ailomaa wrote:
First, ask yourself, if you really need proprietary drivers (and I can't
really speak for the reasons to why you should or should not need them).
The free drivers have in fact become more or less fully functional, so you
might not need the proprietary ones. I was even using the free drivers
playing steam games recently (all though, not problem free).
I wanted to get away from dual booting (Win7) to run a racing sim and
found SpeedDreams on Linux really quite good. I haven't tried it with
Nouveau drivers yet, but I don't expect it to be as good, if it works
at all. The nvidia 310 driver is particularly good, I find, and hardly
stretches my GPU while (playing) driving.
This is not a desktop problem at all. So, it
doesn't matter if you're
using XFCE, KDE
or Gnome. The only two things that are involved is the kernel (and
associated libraries and tools), and the driver.
to build the nvidia kernel module you need the headers for the kernel you
are running, but that should take care of itself when you install
something like nvidia-304. Make sure you are running the kernel you are
intending to build the module for, before proceeding.
Also, move your xorg.conf, if you have one.
Thanks for that. The distro is pretty cutting edge at 13.04, so I
thought there could have been some problem caused by its newness lol.
There's the method of using Software Sources
(software-properties-gtk),
under the tab "Additional Drivers", where you can select a number of
options.
You get the same result when installing from the terminal. All I did was
"sudo apt-get install nvidia-304". This was on "3.8.0-6-lowlatency".
There's always the chance that previous kernels did not work well with the
proprietary drivers.
Yes I found that tab in the 'software and updates' dialog. Thank you.
The 310 driver is well worth trying, if you haven't already. It is
said to double the performance over 304:
"Comparing 304.51 driver performance of 142.7 fps versus 310.14 driver
performance of 301.4 fps in beta build of Left for Dead 2. All tests
run on the same system using Intel Core i7-3930K CPU @ 3.20GHz with 8 GB
memory, GeForce GTX 680 and Ubuntu 12.04 32-bit."
http://nvidianews.nvidia.com/Releases/NVIDIA-Delivers-Massive-Performance-B…
--
4237
days inactive
4240
days old
linux-audio-user@lists.linuxaudio.org
19 comments
7 participants
participants (7)
-
david -
Gene Heskett -
John Murphy -
Kaj Ailomaa -
Len Ovens -
Ralf Mardorf -
Robert Vogel