Geoff King a écrit : I've been having a problem which isn't directly to do with audio—it's to do with the Ubuntu realtime kernel—but I haven't got any answers from the Ubuntu forums and this is a real showstopper as far as doing audio work goes. I've tried the ubuntu realtime kernel several times. I'm not suprised by your findings. Check out these links. I would suggest you file a bug report to ubuntu launchpad. Thanks David and Geoff. It doesn't look very well, does it? I certainly had realtime working on this machine at some time in the past because I remember launching and using Ardour. Did all these problems creep in with Intrepid? I actually tried disabling networking before suspending last night. This time the interface didn't lock up immediately, but a whole raft of things went weird one after the other, taking me to the point where I had to hold down the power button for five seconds. Disabling networking altogether is not an option because I need to be able to switch between different activities easily; this isn't a dedicated audio workstation. Do you really need -rt for your work? Unfortunately, because I do actually need to work with audio in real time, I do need -rt. I shall certainly file a bug report, but I notice that the existing bug reports have been assigned low priority. Since it doesn't look like these problems are likely to be fixed anytime soon, I'm getting to the point where I have to consider ditching Linux and using Windows for everything. I need to be able to do a bit of audio work here and there and then get back onto other things, so rebooting all the time is not an option. The only other option would be to consider switching to a more audio-oriented distribution, by which I mean one that will also let me do normal desktop stuff (Gnome, Skype, Amarok, aMule etc. etc.) without too much hassle – I don't have the time to do the Gentoo thing over again. Would something like Fedora/Planet CCRMA fit the bill? I notice however that on the main Planet CCRMA page it says that not all packages have been compiled in 64 bit versions. Does that mean I should forget the idea? Robert _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Good point. Although I'm not using the -rt kernel anymore, my ubuntu jaunty (and intrepid before it) system works very well for audio stuff. I easily run ardour and jack and others and they are very stable. I found that I did not need the super low latencies (<5ms) from a -rt kernel to do the recording and playback that I was doing. Last time I had a really good -rt kernel was around Gutsy. I did a lot of tweaking for that also, but it did work very well with the workstation. Also FWIW I was never impressed with WindowsXP's latency - Stopped using that about 2.5 years ago and never could get the latency down low enough for live playing using a software synth. So one should not just assume that Windows will give you the super low latencies of a -rt kernel. The best low latency I've ever gotten from my current desktop was using the 64Studio distro a few years ago. But I've never tried the Fedora, Suse, Mandriva versions so can't comment on these. Hope this helps someone. Geoff

Raffaele a écrit : > Did you try to compile kernel 2.6.29.1 with patch-2.6.29.1-rt7?

Thanks Raffaele, and everyone, for your responses. I have built a 2.6.29.1-rt7 kernel. I had to do it the old-fashioned way because I found the instructions for kernel-package incomprehensible unfortunately, and I couldn't work out how to make an initrd, so it took a bit of guesswork to build in the right drivers to make it boot.

But I do at least now have a kernel that works for normal operation, including suspend and resume.

I haven't tested it yet for realtime work, but I doubt there will be any hiccups that can't be easily fixed. So as I said, many thanks :) Robert

2009/4/17 Geoff King &lt;gsking1(a)gmail.com&gt; Did you try to compile kernel 2.6.29.1 with patch-2.6.29.1-rt7? As on every debian based distro it is very easy to compile a customized kernel using kernel-package.

Ken Restivo a ??crit : I have 3Gb of memory and hibernating takes a year and a day, much longer than it would take to shut down, reboot, and open all my applications again, so until hibernation to a compressed image becomes available (would it not be possible for instance to zero the unused memory and then pipe the used and unused memory contents through a compressor?), it isn't an option unfortunately.

As far as I can remember, I have hyperthreading enabled in the bios, but it doesn't seem to be giving me any problems.

So basically, as I said before, apart from the hibernate issue, which can be worked around easily, the latest rt kernel seems to be working like a charm. The main challenge now, will be to make jack2 survive through a suspend-resume cycle, which is something I never managed to do in the past.

Ken Restivo a ??crit : Wasn't that what they said about getting Jack working in Windows? I know the devs have a lot on their plates and that nothing like that is going to happen next week, but all the same, I hope you're wrong ;) The laptop age means computer music for people with short attention spans. Continuity over sleep cycles would definitely be useful.

What about adding a pair of callbacks to the JACK API that could be registered with the suspend/resume system?  When the system invokes the suspend callback Jack would mute audio output then go into soft mode, ignoring all xruns and client timeouts until further notice, then drop RT scheduling.  The resume callback re-enables RT, and a few cycles later resumes the normal timing checks and unmutes audio when no xruns or client timeouts have been detected for a few consecutive cycles. The only changes would be to jackd itself AFAICT.