On Fri, 2004-07-16 at 10:25, Florian Schmidt wrote:
> after reading lee's email i had to try this kernel.. so i went over to www.de.kernel.org, grabbed 2.6.8-rc1 and patched it up with this patch:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/1453.html
>
> On first sight it looks very good. many of the sporadic xruns i experienced
> with jack in RT mode are gone. even a "find /" parallel to a "make bzImage"
> seems not to provoke any xruns [i use ext3]. But: i use fluxbox and it supports
> desktop wheeling [switching desktop via scrollwheel - very handy] and doing this
> excessively and rapidly provokes xruns easily. Also starting mozilla just provoked
> an xrun..
Try the included patch. Andrew Morton suggested this, and it works
great for me, but it is not in -mm1.
Lee
--- drivers/char/tty_io.c_orig 2004-07-16 16:10:11.000000000 -0400
+++ drivers/char/tty_io.c 2004-07-16 16:10:31.000000000 -0400
@@ -679,17 +679,13 @@
return -ERESTARTSYS;
}
if ( test_bit(TTY_NO_WRITE_SPLIT, &tty->flags) ) {
- lock_kernel();
written = write(tty, file, buf, count);
- unlock_kernel();
} else {
for (;;) {
unsigned long size = max((unsigned long)PAGE_SIZE*2, 16384UL);
if (size > count)
size = count;
- lock_kernel();
ret = write(tty, file, buf, size);
- unlock_kernel();
if (ret <= 0)
break;
written += ret;
On Fri, 2004-07-16 at 04:33, Malcolm Baldridge wrote:
> > Some of these fixes were to
> > extremely important areas (get_user_pages, a fix for
> > framebuffer-scrolling issue, and more).
>
> It goes against common sense (to anyone with kernel knowledge) to use the
> console framebuffer anyway.
>
> The duration of kernel locks and the CPU expense of blowing bitmaps around
> like that are shocking.
>
> Seriously. Use text-mode consoles, or a native AGP-driver a la nvidia, ati,
> or whatever. But using a "stupid" framebuffer driver is asking for hardcore
> latency blow-outs.
>
I am using text-mode consoles, and switching back and forth between
those and X using ctrl-alt-F[1-7]. I sent Andrew Morton some XRUN
traces and he said one of them was caused by framebuffer scolling inside
lock_kernel(), and the fix was to remove (un)lock_kernel() from
do_tty_write(). This particular fix may not be in -mm1, because he
seemed to think it would cause problems (display corruption, etc). It
has not caused any problems for me.
Maybe I am confused about the 'framebuffer' vs. a text-mode console, I
thought they were the same. Anyway, the point is, switching from X to a
text-mode console and back caused XRUNS before, and now it doesn't.
Lee
Please pardon cross-listing...
The deadline for the ICMC 2004 "Early Bird Registration Rate" is coming
up soon. Please register on-line by July 29, 2004 to take full advantage
of reduced rates. Regular rates will be applied after July 29, 2004 and
on-site registration rates after October 27, 2004. Please refer to
http://www.icmc2004.org for details. Thank you.
Sincerely,
Tae Hong Park
I'd like to announce a new version (numbered 0.4) of the DSSI synth
plugin API proposal.
http://dssi.sourceforge.net/
Disposable Soft Synth Interface (DSSI, pronounced "dizzy") is a
proposal for a plugin API for software instruments (soft synths) with
user interfaces, permitting them to be hosted in-process by audio
applications. DSSI 0.4 was constructed by Steve Harris, Chris Cannam,
and Sean Bolton.
DSSI is intended to be simple, especially for plugins;
GUI-toolkit-agnostic; and slightly biased towards familiarity with
MIDI. It's proposed as an interim measure until bigger and better
things come along: hence "disposable".
The 0.4 release addresses the problem of efficiently managing shared
resources among instances of a plugin by providing explicit support
for plugins that may be run in a group. It also clarifies issues
such as thread-safety and fixes a few other problems with the 0.1 API
identified on LAD and elsewhere. We think the 1.0 release could look
pretty much the same as this 0.4 version, barring any more stupid
mistakes.
The release contains the RFC, the dssi.h header file, example host and
plugin code, and now the all-important FluidSynth wrapper plugin.
Comments to LAD please.
Chris
As mentioned briefly, Dave Phillips innocently asked me about SoftWerk
while we were riding on the train from Paris to Bordeaux last week. I
thought "how hard could it be to get it working again?" and thereby
hangs a tale (and a tail).
To cut a short story shorter:
http://linuxaudiosystems.com/softwerk/softwerk-2.0.0.tar.bz2
is an *initial* re-release of my "analog pattern MIDI sequencer". It
is modelled on the Doepfer Schaltwerk, a gorgeous beast of a machine,
except that SoftWerk can do everything the SchaltWerk can, and then
quite a bit more :)
To compile it, you will need (i think):
gtk+ 1.2
ALSA with sequencer support
gcc/g++ < 3.4
This is a provisional release - I believe that this tarball will
ccompile and install and be usable by most people, but what I'd like is
for a few people to try it out before I update sourceforge and make
other announcements.
The documentation at softwerk.sf.net is still reasonably accurate,
except that mouse motion is no longer used for editing step values,
only typed numerical values or the arrow keys.
have fun,
--p
Hi,
I am happy to announce the first release of WONDER.
The program WONDER (Wave field synthesis of new dimensions of
electronic music in realtime) is designed to provide an interface
between a wave field synthesis system and the software or hardware
composers and performers of electronic music are used to. The program
is still in development and trying to reach its eventual goal step by step.
The current version (v2.0) allows the user to either create a
composition for the movement of the sound sources in his composition
or to control the movements in realtime, either via the gui or via
open sound control.
The program is released under the GNU General public license. Feedback
and bug reports are very welcome: wonder(a)nescivi.de
The program is created by Marije Baalman and Daniel Plewe (OSC
implementation) and is developed in the Electronic Studio of the TU
Berlin.
WONDER is created for Linux (X11) and uses the
Free Qt-Libraries (v3.0.2b or higher),
libOSC++ libraries and
BruteFIR (v0.99n or higher).
Basic installation info can be found in the package in the INSTALL
text. The README file lists some extra requirements and necessary
adaptations for BruteFIR.
Furthermore a soundcard with a lot of outputs and a lot of speakers
are required, to make practical use of the program.
At: http://gigant.kgw.tu-berlin.de/~baalman/
you will find a description of what Wave Field Synthesis is and under:
program - download
you will be able to download the program as a tar-ball.
The manual with screenshots is also online.
The software is by far not yet bug-free, but in my experience it is
usable and generally it does not crash when running the audio (except
if external conflicts happen or the processor is overloaded). See the
KNOWBUGS file that comes with the package...
sincerely,
Marije Baalman
--
On Thu, 2004-07-15 at 04:53, Damien Cirotteau wrote:
> On Thu, Jul 15, 2004 at 10:35:47AM +0200, Free Ekanayaka wrote :
> > |--==> "DC" == Damien Cirotteau <damien.cirotteau(a)agnula.org> writes:
> >
> > DC> Hi all,
> > DC> some very interesting links submited by simmo on IRC
> >
> > DC> File system:
> > DC> http://kerneltrap.org/node/view/3466
> >
> > DC> Voluntary Kernel Preemption:
> > DC> http://kerneltrap.org/node/view/3440
> >
> > Yes these are definitively interesting!
> >
> > I'll read them carefully and see if we can adopt some new trick :)
>
> Two first thing that i can retain:
> - Don't use reseirfs for now (especially with 2.6)
> - Enable CONFIG_SND_DEBUG in the kernel so it will be easier to trace
> the xruns. It looks that it is a very useful feature to understand where
> the xruns comes from and is very good feedback to send to kernel folks
The intrepid user in need of low latency should try 2.6.8-rc1-mm1. I
sent a bunch of XRUN traces to Andrew Morton, and this kernel contains
numerous latency fixes as a result. Some of these fixes were to
extremely important areas (get_user_pages, a fix for
framebuffer-scrolling issue, and more). The improvement should be
major. He is going to be unavailable until July 26th, so the next few
weeks are a great opportunity to test and collect data.
You are correct in that reiserfs as shipped with the kernel should
probably not be used for now if you need low latency. However, I
strongly suspect that SuSe (which users reiser by default) contains
fixes for this which are not in the mainstream kernel. By enabling
CONFIG_SND_DEBUG *and* turning on XRUN debugging at runtime (echo 2 >
proc/asound/cardX/pcmX/xrun_debug) you will be able to see whether this
is affecting you.
Here is the announcement:
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/1453.html
Lee
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
>
> >It's too bad that the multimedia community didn't participate
> >much during the 2.5.xx development leading up to 2.6.0. If they
> >had done so, the situation might be different today. Fortunately,
> >fixing up the multimedia problems isn't too risky to do during
> >the stable 2.6.xx series.
>
> I regret that this description is persisting here. "We" (the audio
> developer community) did not participate because it was made clear
> that our needs were not going to be considered. We were told that the
> preemption patch was sufficient to provide "low latency", and that
> rescheduling points dotted all over the place was bad engineering
> (probably true). With this as the pre-rendered verdict, there's not a
> lot of point in dedicating time to tracking a situation that clearly
> is not going to work.
No, this is wrong. 2.6+preempt can satisfy your latency requirements
without any scheduling points. All it requires is that the long-held locks
be addressed. I've already done a metric ton of work in that area (notably
removal of the buffer_head LRUs and rewriting the truncate code) but more
apparently remains to be done. We know that reiserfs has problems.
But what can I do? I set up a preempt-on-ext3 test box, thrash the crap
out of it and see 300 usecs worst-case latency. So I am left empty-handed,
wondering what on earth is happening out there.
I am deeply skeptical about claims that autoregulated swappiness can make
any difference.
I am deeply skeptical about claims that CPU scheduler changes make any
difference. A scheduler change shouldn't improve responsiveness of
!SCHED_OTHER tasks at all, so perhaps there are application priority
inversion problems, or applications aren't setting SCHED_FIFO/RR correctly.
I do not know.
I am also fairly skeptical about claims that voluntary-preempt helps,
because it only pops a couple of locks, and I doubt that testers are
hitting the code paths which those changes address anyway.
So Something Is Up, and I don't know what it is.
Please double-check that there are no priority inversion problems and that
the application is correctly setting the scheduling policy and that it is
mlocking everything appropriately.
And please ensure that people are setting xrun_debug, and are sending
reports.
> The kernel is not going to provide adequate latency for multimedia
> needs without either (1) latency issues being front and center in
> every kernel developer's mind, which seems unlikely and/or (2)
> conditional rescheduling points added to the kernel, which appears to
> require non-mainstreamed patches.
>
Nope, the conditional rescheduling points provide zero benefit on a
preemptible kernel.
Something weird is happening, I don't know what it is, I cannot reproduce
it and I need help understanding what it is, OK? The sooner we can do
that, the sooner it gets fixed up.
Greetings:
As promised, here's a set of test criteria used by Alan Belkin in his
1994 review of notation programs for the Macintosh. I hope that the
authors of Linux music notation software will consider this list against
the features of their own efforts.
I'm not interested in comparing "ours against theirs". The Mac
programs tested were all WYSIWYG notation editors, including Finale,
Composer's Mosaic, Encore, Lime, and Nightingale, while some of the best
Linux music notation software is devoid of any GUI. Nevertheless, the
criteria seem adequate as base requirements for any music notation
software, and I'm very interested in the opinions and evaluations of the
Linux developers of such software. I know that the authors of NoteEdit,
LilyPond, MusE/Musescore, Denemo, Rosegarden, Common Music Notation, and
perhaps other significant notation editors are represented on the
LAD/LAU lists, and I hope they will respond on-list to the criteria
presented here. I also welcome comments from users regarding the
presence or absence of the listed features in their favorite Linux
notation program.
I have only slightly altered Mr Belkin's original criteria where it
was Mac-specific. The evaluations in his original article were either
qualitative (good, bad, ugly, etc), quantitative, (1, 4, 12, etc), or
affirmative/negative (yes/no). So, here we go:
Note entry:
mouse & keyboard
MIDI step-time
MIDI realtime w. flexible quantization
audition other saves while recording
retain performance data for playback
number of independent rhythmic layers per staff
maximum number of staves per system
Entry of slurs, articulations, dynamics, etc.:
intelligent default placement
apply to multiple staves at once
Selection in regional edits:
vertical, horizontal slices within and across measures, staves,
system, pages, etc.
non-contiguous
conditional selection
Editing:
click & drag positioning of symbols
transposition (note, staff, selection, etc)
enharmonic change by region
rhythm: change note values (ease of use)
rhythm: auto-rebar
cut/copy/paste: music
cut/copy/paste: non-musical items, formats, etc.
mirroring (intelligent copies)
Special/custom notation:
unusual staves
simultaneous key signatures
unconventional time signatures
additive time signatures
simultaneous different time signatures
drawing tool
user-created symbols
user-selectable fonts for all elements
chord notation: graphic, playback, learn via MIDI
fretboard notation
figured-bass notation
unusual note heads (slashes, harmonics, etc)
easily adjustable cross-staff beaming
Lyrics:
mass create
create on page
import from text editor
auto layout
multiple fonts
flexible placement
MIDI playback:
ALSA or OSS support
channel support
playback includes modifiers (crescendi, dynamics, etc)
direct editing of MIDI data
import patch lists (GM, GS, etc)
scrolling playback
edit during playback
Entry layout:
flexible engraver spacing within measure
account for dynamics, slurs, annotative text, etc.
Page layout:
auto layout with engraver spacing
reduce or enlarge symbols, staves, text, systems, by any percent,
locally or globally
full control of measures per system
full control of systems per page
remove empty staves within systems
flexible spacing of staves within systems
Part extraction:
automatic with new layout
dynamic links to master score
File operations:
follow Linux standards (?)
simultaneous multiple files open
printed output: PS, PDF, DVI, etc.
Interface/overall ease of use:
undo/redo any operation
user-defined key bindings
user control over notational defaults
views: scroll, page, template, any percent, multiple simultaeous views
priorities clear
logical organization
simple language and icons
overall speed
on-line help
documentation
ease of learning
general solidity and stability
In his article Mr Belkin also addressed the problem of tuplets, noting
that at that time only Finale realized anything other than triplets when
converting from MIDI input (file or realtime). I should also note that
this list is hardly meant to be a complete set of expected features:
after all, it's from an article published ten years ago. I'm sure we've
advanced well beyond the state of the art in 1994... right ? :)
Best regards,
Dave Phillips