---------- Forwarded message ----------
From: porl sheean <porl42(a)gmail.com>
Date: 16 Oct 2007 12:33
Subject: Re: [LAU] difference between realtime-kernel and
low-latency-kernel?
To: Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu>
i think a few people have missed what i mean. after re-reading my post i can
see it wasn't all that clear. i am still using ubuntustudio, but i
downloaded the 64studio *kernel* (not the whole distribution, which i tried
but it wasn't quite what i wanted) to replace ubuntu's. after doing that,
everything runs perfectly. i assumed that the ubuntu kernel didn't have the
rt patches set right, but after downloading a vanilla kernel and patching it
myself i noticed that my custom kernel had the same problems as ubuntu's.
whilst i am happy to use the 64studio kernel, i am very curious as to what
they have done to it to make it work where both the ubuntu-rt and my own
custom kernel both have the same symptoms (*very* unstable audio at lower
than 40ms latency, and even then ardour often refuses to start plaback -
jack drops it off as soon as i press play sometimes on larger projects). i
did a diff of the config files from all kernels and couldn't find any
notable difference that would explain it (to my limited knowledge anyway),
so i assume it is a patch that 64studio has applied in addition to the
standard rt patch that is making the difference. are there any other audio
performance enhancing patches for the kernel?
thanks porl
On 16/10/2007, Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu> wrote:
>
> On Sun, 2007-10-14 at 12:48 +1000, porl sheean wrote:
> > i have actually had no end of trouble with ubuntustudio's (and now
> > ubuntu's) rt kernel. on an amd 6000+ system with 1gig ram and a
> > rme9652 soundcard i can't get reliable performance under 40 or so ms.
> > i even tried a vanilla kernel with the rt patches and had the same
> > trouble. the 64studio kernel worked fine, however. i'm currently
> > running at 5ms with it and have had no problems. this is even with
> > compiz fusion running and spinning the cube whilst playing back audio
> > from an 18 channel ardour project. what patches would cause such a
> > difference in performance? it isn't any options selected in 'make
> > menuconfig' - i loaded the 64studio's ones in and used them. still no
> > luck. i can only assume they have added more patches to do with
> > realtime performance than just the -rt patchset.
>
> >From what I gather ubuntustudio does not have an rt patched kernel (ie:
> patched with Ingo Molnar's realtime preemption patch). See observations
> below:
>
> > On 05/10/2007, thomas fisher <studio1(a)commspeed.net> wrote:
> > I can supply no quantifications for the 32 bit 2.6.20-16-realtime
> > kernel in ubuntustudio other than no xruns have been observed.
>
> So, Ubuntu Studio has a kernel named realtime and they have observed no
> xruns (which is not your case, and not the case of other posters).
> Obviously it depends on how they test (hardware used, size of buffers,
> load on the machine under test, etc, etc) and there's no info on that
> post about that.
>
> > With the low latency kernel, xruns were observed.
>
> This implies they don't have the low latency patches applied and that,
> in their experience, the low latency patch was worse than the mainline
> kernel.
>
> If you have access to that kernel and you can check its build
> configuration you could grep for "PREEMPT" there and post the results.
> That will definitely tell us which options were used for building it (I
> suspect you will find just "PREEMPT_VOLUNTARY" there).
>
> In my experience, a mainline kernel will lead to xruns at low latencies
> (there's always an exception, of course).
>
> > Jack is the only app that has a -20 priority assigned.
>
> This implies they are not using SCHED_FIFO for running Jack. Apparently
> they are boosting the normal scheduler ring priority of Jack to -20. I
> have not experimented with this so I can't comment, except to say that
> everyone else (that I know of) is using SCHED_FIFO for running Jack -
> SCHED_FIFO is a higher priority scheduling method that can't be
> preempted by regular linux tasks, and while it is more risky as a badly
> designed application can hang the machine, the tradeoff is of course
> much better realtime performance.
>
> > The general workstation has been running without fault. The general
> > Debian / Ubuntu philosophy tends towards system stability.
>
> The realtime preemption patch is certainly less stable than the mainline
> kernel. But if you hardware runs it fine then it is more effective than
> mainline for achieving low latencies.
>
> -- Fernando
>
>
> > Tom
> > On Wednesday 03 October 2007 14:54:32 Fernando Lopez-Lezcano
> > wrote:
> > > On Wed, 2007-10-03 at 18:39 +0200, Frank Barknecht wrote:
> > > > Hallo,
> > > >
> > > > Matthias Schönborn hat gesagt: // Matthias Schönborn
> > wrote:
> > > > > I've just read that there's a difference between a
> > realtime-kernel and
> > > > > the low-latency-kernel provided by ubuntustudio. The
> > text in the german
> > > > > wiki on ubuntuusers.de said, that a realtime-kernel is
> > slightly better
> > > > > than the lowlatencykernel
> > ( http://wiki.ubuntuusers.de/Echtzeitkernel ) -
> > > > > then why isn't it used in ubuntustudio? Or do I just mix
> > something up?
> > > >
> > > > I think, this wiki and maybe Ubuntustudio as well are
> > using a very
> > > > confusing terminology.
> > > >
> > > > Generally we have two kinds of kernels: The "vanilla"
> > kernel as
> > > > downloadable on kernel.org and the same kernel, but
> > patched with Ingo
> > > > Molnars RT-patches. The vanilla kernel, if configured
> > properly with
> > > > CONFIG_PREEMPT etc., already gives very good performance
> > in the low
> > > > latency department, enough for many users, even audio
> > users. I run one
> > > > of these.
> > > >
> > > > If you want more, then you can install a RT-patched
> > kernel, as is
> > > > provided in the linux-rt or linux-realtime packages. I
> > would call the
> > > > Ingo-Molnar-patched kernels Realtime-Kernels or
> > Low-Latency-Kernels.
> > >
> > > To further clarify (or confuse?) the issue, how "low
> > latency" the kernel
> > > is also depends on how you configure the kernel build
> > options before or
> > > after patching the kernel with Ingo's patch. For Ingo's
> > patch
> > > CONFIG_PREEMPT_RT is the best option in terms of latency but
> > there are
> > > others (CONFIG_PREEMPT_DESKTOP) that have a more
> > conservative approach
> > > but have (relatively speaking) higher latencies. So from
> > worst to best
> > > it would be something like:
> > >
> > > vanilla linuz + CONFIG_PREEMPT_NONE
> > > vanilla + CONFIG_PREEMPT_VOLUNTARY (used by the stock
> > Fedora kernel)
> > > vanilla + Ingo + CONFIG_PREEMPT_DESKTOP
> > > vanilla + Ingo + CONFIG_PREEMPT_RT (the one I use for
> > Planet CCRMA)
> > >
> > > (there's more granularity and options in the CONFIG_PREEMPT*
> > world but
> > > those are the ones that have the biggest impact as far as I
> > can
> > > remember)
> > >
> > > -- Fernando
> > >
> > >
> > > _______________________________________________
> > > Linux-audio-user mailing list
> > > Linux-audio-user(a)lists.linuxaudio.org
> > >
> >
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
> >
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> >
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
>
Hi!
Well, we did it, but it's in a beta stage. Now you can upgrade from Musix
0.99, 1.0 RC1, R1 or R2 to R3 (cd version, not DVD) without even the new
Live-CD 1.0 R3 Test1.
Just open a Terminal and type:
sudo apt-get update
sudo apt-get install musix1.0r3-upgrade
(Note: you must use sudo if you want to upgrade your personal Desktop files...
dont do it as a "simple" root user)
New:
* Linux 2.6.23-rt1
* Ardour 2.1
* Musix Control 1.4.1
* Canorus 0.3.1
* jackd 0.103.0
* horgand 1.12
* xfe 1.04
and many more...
Some bugs were corrected, so, it's clever to upgrade :)
Regards,
--
MGG
<sigh>
My last message to the list was asking for help getting a real-time kernel for
openSUSE 10.2. Sadly it was never resolved - there are kernel-rt packages
available for 10.2, but they were out of step with the kernel-source package.
I've now migrated to 10.3, because I was aware that an RT kernel was being
developed for it. Sadly, when I got to the RT kernel I noticed that the
package in the main repository was still at the original shipped kernel
version (2.6.22.5-31).
The default kernel and kernel source packages have both moved on to
2.6.22.9-0.4 - so if I install the RT kernel, I will not be able to install
the NVidia driver for it.
I am now trying to downgrade the kernel and sources to the original shipped
version so I can try the RT version. Does anyone have any advice that might
help?
--
David Haggett
Can anyone suggest a couple of ALSA-safe cards that
will provide "bit perfect" SPDIF throughput ?
In other words, if I play back a 44.1khtz CD that the
card will not resample the signal, at all, on the way
through to the SPDIF output.
And, in the case of a nVidia MCP67 (hda_intel), which
seems like it does 96k and 192k, is there some way I
can determine how well, or not, it passes through any
digital signal?
--markc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks for pointing me to nted. It looks *very* useful. Simple, clean, easy to learn, and lots of keyboard shortcuts.
But the most amazing thing about it is: it doesn't try to produce its own sound or have any sound engine of its own! This is, I think, its most brilliant feature. No soundfonts, no sound drivers, nothing. All it does is access the ALSA sequencer and send MIDI to my JACK softsynths. So I can note something out and hear it with my own synths.
Some bandmates and I were just lamenting how paper and pencil is so much easier to deal with than most notation software out there. Maybe not. nted looks like it might even be easier than paper and pencil.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHFbgDe8HF+6xeOIcRAsa6AJ992FQ3WixbeuepaZTeliIdSiiJagCgqKYF
NOcvepQVRZbCrXkeRh3yXm4=
=TBUb
-----END PGP SIGNATURE-----
I have a soundblaster as card0 and a Delta44 as card1.
I want to keep it this way so that most trivial sounds
come through the soundblaster, and leave the Delta44 open
for use as a serious soundcard.
Lately, I've been having trouble getting any decent
sound editor to use the second card. Audacity should
do it, but on my Kubuntu system, it crashes when opening
or playing a file. I find this in my log:
alsactl: resmgr: communication failure: Connection refused
or
audacity: resmgr: communication failure: No such file or directory
So, unless I can get it to work, I'm stuck with other editors.
It's amazing, but many of the decent looking editors will not
allow any configuration of device, and always use /dev/dsp0.
That sucks. Now, when they do allow me to select the second
card as /dev/dsp1, I get errors about the format not being
supported. This is because the Delta is really a 12 channel
card without hardware for the extra channels. In properly
written alsa programs, I can use hw:plughw1,0. But I haven't
found any decent editor that will let me specify something
like this.
Now I'm wondering whether I can do something tricky in
my /etc/asound.conf that would let the unaware programs
use my Delta44. I look at the docs (such as they are)
once in a while, but I never come up with anything valuable.
Just today, I started by making a simple slave:
pcm.delta {
type hw
card 1
device 0
}
pcm_slave.sltest {
pcm delta
}
pcm.live {
type hw
card 0
device 0
}
But aplay will not use -D sltest:
ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM sltest
aplay: main:547: audio open error: No such file or directory
I don't know how to go about getting a better understanding of
this most arcane config file.
Thanks,
Tobiah
--- joq(a)io.com wrote:
On 17 Oct 2007 01:58:08 -0000, arisstotle.54695488(a)bloglines.com
> <arisstotle.54695488(a)bloglines.com> wrote:
> > This is most strange to
me. Weeks ago, I configured pam to allow the audio
> > group to operate high
priority real time precesses. I could start jackd and
> > it would run as
priority 80, for example. However recently Ardour constantly
> > disconnects
from jack, and look at the output of top, jack seems to only be
> > runing
at the default priority of 20, regardless of the settings I pass on
> > the
command line. thoughts?
>
>
> What command line do you use?
> --
>
joq
>
$:jackd -R -P 80 -d alsa -p 64
This is most strange to me. Weeks ago, I configured pam to allow the audio
group to operate high priority real time precesses. I could start jackd and
it would run as priority 80, for example. However recently Ardour constantly
disconnects from jack, and look at the output of top, jack seems to only be
runing at the default priority of 20, regardless of the settings I pass on
the command line. thoughts?
hi
My question is fairly long to explain, but simple to summarize: why are we
experiencing delays in playing music compositions using GNU Denemo under
Edubuntu over a GB network that should be performing better, and what can we
do to solve the problem without spending any money?
I am a volunteer supporting a public middle school with FOSS. We have a
brand new dual core server with 2 GB of RAM whose only purpose in life is to
support 24 chubby clients running edubuntu. The thin clients have at least
256 MB of RAM, and most of them have swap space on their hard drive also,
although some of them are true thin clients in that the hd has no swap and
is basically a vestige. I am told that we have a gigabyte network. The
server feeds the signal to the first 18 clients through one GB switch, and
then that switch feeds another identical switch with services about 6 more
clients.
Our problem is that when we use GNU Denemo to play the short little
compositions that the students write in class, we can have only one student
play his / her composition at a time or the system is choked, meaning that
it lags. More specifically, all of the students find that their GNOME
desktops are almost completely non-responsive to the mouse. The mouse still
moves, but programs launch very slowly for about 5 mins, at which time the
choke point is presumably cleared, and then one student can again play his /
her composition. It might be possible for, say, 2 students or maybe even
three students to play their music; but we don't know where that stress
point is.
And, in some ways, it doesn't even make sense to slowly add students and
have them play music, simply because some people who have heard of this
problem in passing furrow their brow and say that we shouldn't be having
these problems.
We are, of course, going to be trying to get more RAM in the clients; and
swap for all of the clients; and we have thought of running GNU Denomo
natively on each of the clients by booting them as stand alone work
stations. But I am a volunteer, and this inner city school has absolutely
no budget for a real tech support person, and all of the teachers already
are at work by 6:50 a.m., and they usually stay until 6:30 p.m., and then
each of the teachers is expected to be available to field phone calls at
home until 8 p.m. All of this might sound kind of drastic, but our students
typically come to this school of 290 students under-performing their grade
level by 2 grade levels, but leave the school as 8th graders typically
performing at or above grade level. Seventy-five (75%) of our students come
from households below the federal poverty guidelines. 65% of our students
are African American; 17% are Latino; 10% are Asian; and 8% are Caucasian.
Despite the life challenges facing our students, last year our students
tested in first place (as a student body) based on standardized testing. So
this school is succeeding in many ways, but they are really struggling in
terms of technology, and that is all because of funding shortfalls.
Coincidentally, the students spend no time here on Windows boxes, except for
occasionally random Internet browsing on a teacher's Windows box. But that
is the exception, because, as you can imagine, the teachers don't want the
students accessing their computers. So when the students are not in the
lab, they are using PClinuxOS boxes in several of the classrooms to do their
Internet research.
Overall, this school is making miracles with no funding. I am hoping to
move the whole school to FOSS eventually, but of course there is still a lot
of work to be done. Thus far, the music teacher is fairly impressed with
the ability of students to compose music on GNU Denemo, but she would just
like to be able to have all of the students listen to their compositions at
the same time. Typically, these compositions are no more than, say, 6 or 10
bars long, just enough to get the students familiar with the basics of
scales, rests, note duration, tempo, beat, etc. Just the basics.
Thanks in advance for the help.
--
Christian Einfeldt,
Producer, The Digital Tipping
Point<http://archive.org/details/digitaltippingpoint>
Hello all!
I group I recently joined is doing a gig in two weeks. After a few
months of practicing, there are still a few tunes that I don't have
memorized, so I need to generate a lead sheet pretty quickly. I could
write them out by hand fairly easily, but I would like to keep a
digital library of leadsheets. Is there a program that will generate
"realbook-style" leadsheets for Linux? I basically need just a simple
staff with what I call rhythm slashes, and a mechanism for putting
chord symbols above the staff. (Jazz players who have spent many
nights in a dark room reading the original - and illegal - Real Book
know exactly what I'm looking for here.)
I realize there are complex tools like Lilypond that will probably do
this, but I would like something simpler, maybe with a gui.
Thanks!
--
Josh Lawrence
http://www.hardbop200.com