Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>> i know that gstreamer (and perhaps GLAME too) appear to have worked
>> these issues out. if so, thats great, and i hope that their designs
>> can be incorporated into jackd at some point, so that (1) if there are
>> independent substreams and (2) there are more than 2 processors then
>> it could support multiple audio threads. there are some vague ideas
>> present in the existing code base that point in this direction.
>
>Well, I don't think GStreamer has completely worked things out yet.

all i meant was that i think both gstreamer and glame can (correctly)
identify independent subgraphs in the overall graph. the rest of their
infrastructure and design isn't relevant apart from where it affects
their ability to do this.

can someone correct me if i'm wrong about this ability?

--p

[linux-audio-dev] lilypond and GUIDO (WAS: Project XEMO, MusicXML)(fwd)

[Michael Droettboom]

I have an extended comparison of GUIDO and Mudela as part of my Master's
thesis-in-progress.  It exists in an earlier form at:

http://mambo.peabody.jhu.edu/~mdboom/format.pdf

I must warn all readers, however, that this document is over a year old
and is no longer very current and may contain factual errors.  Let's
not start a flame war, because I believe both languages have their
place, but I thought this might provide more food for thought and
discussion.  For my own work, GUIDO was the clear choice, but your
needs/mileage my vary.

Excerpt from the conclusions of the revised version:

For an end user typing in music directly, Mudela's concise syntax can
be learned easily.  GUIDO's more verbose syntax can be cumbersome at
times.  The human issues of entering the representation manually,
however, was not a strong consideration for the present system.

The availability of software tools is also an important factor.
Presently, the freely available GUIDO tools are not fully functioning,
while LilyPond is stable and quickly approaching the level of
professional-quality output.  I have not evaluated the commercial
GUIDO tools, but regardless of their design or usefulness, it may be
problematic to embark on an open-source project whose only possible
interchange is with a commercial product.

>From the point-of-view of an implementor, GUIDO is a much more elegant
and practical language than Mudela.  It is clearly defined and its
design ensures language stability even as new extensions are added.
The available GUIDO parser kit is well designed and easy to use by
developers.

Clearly, choosing a musical representation language for any project is
a difficult task.  In the end, for the OMI project, we decided not to
decide: to ensure that the OMI system was extensible enough that to
new output formats could be added as easily as possible.  However,
GUIDO is gradually winning over as our language-of-choice for the
long-term archiving of scores.  GUIDO's superior design should ensure
that it receives wide-acceptance, but until then leaving OMI as open
as possible seems to be the best solution.

Regards,
Mike

-- 
Michael Droettboom
[EMAIL PROTECTED]
410.625.7596

Computer Music Research
Peabody Conservatory of Music
Johns Hopkins University

-- Forwarded message --
Date: Wed, 14 Nov 2001 23:15:13 -0200
From: Nelson Posse Lago <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [linux-audio-dev] lilypond and GUIDO (WAS: Project XEMO, MusicXML)

On Wed, Nov 14 2001 at 08:28:54am -0500, Karl MacMillan wrote:
> [...] Supporting basic music notation is fairly straightforward, but
> providing all of the functionality to support complex, modern notation is
> difficult. See Guido for a format that does a good job at the harder parts
> of notation - http://www.informatik.tu-darmstadt.de/AFS/CM/GUIDO/

Well, the advanced examples are all Bach, so I'm not sure if by "modern"
notation you mean 20th-century notation. If not, how do you feel this
format compares to the format used by lilypond? After all, lilypond at
least has a free parser/processor that generates good quality output on
linux...

See ya,
Nelson

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Charles Iliya Krempeaux]

Hello,


On Wed, 2001-11-14 at 14:19, Paul Davis wrote:


> i know that gstreamer (and perhaps GLAME too) appear to have worked
> these issues out. if so, thats great, and i hope that their designs
> can be incorporated into jackd at some point, so that (1) if there are
> independent substreams and (2) there are more than 2 processors then
> it could support multiple audio threads. there are some vague ideas
> present in the existing code base that point in this direction.

Well, I don't think GStreamer has completely worked things out yet.
GStreamer is based on the GObject object-system.  (The same one used by
Gtk+, GNOME, etc.)  And although this system has the possibility
of runtime=discovery of "properties" (of these objects), nothing
like that exists for "methods".  Which makes things extremely difficult
to move things to other processes.  Not to mention that threre are a
whole bunch of other problems with doing IPC with GObject based stuff
too.  (Like GObject is _NOT_ thread safe.  The type system is not a
global thing that is the same across all process, but is infact 
different for each and every process.  And other stuff too.)

Alot of GStreamer, so far, seems to be locked in one process; although
you still have threads.

I'd like to see the GStreamer API changed a bit.  And hopefully I can
help fix things.  (But I'm still learning it.)

See ya

 Charles Iliya Krempeaux
 tnt @ linux.ca
 ckrempea @ alumni.sfu.ca

[linux-audio-dev] lilypond and GUIDO (WAS: Project XEMO, MusicXML)

[Nelson Posse Lago]

On Wed, Nov 14 2001 at 08:28:54am -0500, Karl MacMillan wrote:
> [...] Supporting basic music notation is fairly straightforward, but
> providing all of the functionality to support complex, modern notation is
> difficult. See Guido for a format that does a good job at the harder parts
> of notation - http://www.informatik.tu-darmstadt.de/AFS/CM/GUIDO/

Well, the advanced examples are all Bach, so I'm not sure if by "modern"
notation you mean 20th-century notation. If not, how do you feel this
format compares to the format used by lilypond? After all, lilypond at
least has a free parser/processor that generates good quality output on
linux...

See ya,
Nelson

RE: [linux-audio-dev] Project XEMO, MusicXML

[Tim Goetze]

Today Karl MacMillan wrote:

> I have seen at least a dozen XML formats for symbolic music
>representation over the last two years and they have all been either
>incomplete or just not caught on. This is a harder problem than it seems at
>first. Supporting basic music notation is fairly straightforward, but
>providing all of the functionality to support complex, modern notation is
>difficult. See Guido for a format that does a good job at the harder parts
>of notation - http://www.informatik.tu-darmstadt.de/AFS/CM/GUIDO/ - and my
>project for an application that uses it - http://mambo.peabody.jhu.edu/omr/.

thanks for the links and thought. i guess which format to use is very much
up to your background - for example if you drive MIDI devices you'll 
probably use something close to MIDI. CMN for another is obviously
well-suited for the subtleties of actual score setting.

something i do like a lot about XML is the verbosity. i find CMN for
example almost unusable (though still very attractive) without frequent
looks at the manual. another good thing about XML is that the syntax
is so easy you understand it without a manual at all. cannot say much
about Guido yet but i suspect people like me will find it harder to read
and/or write than XML for these reasons.

tim

[linux-audio-dev] low-latency/smp bug? deadlock?

[Christopher Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I appear to be having problems with the low-latency patch for 2.4.14.  I
get freezes at various points soon after boot: no oops.  It's an dual PII
450Mhz machine and I was curious if anyone else had seen problems with the
recent LL patches under smp.

The machine has no problems with plain 2.4.14 or with rml's preemptable
kernel patch and I've been happy using low-latency patches for 2.4.9 and
2.4.10ac11 previously.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard 

iD8DBQE78wExQz4OF11RXxYRAsuYAKCRu28rdS2jyJM/+A9mPxGVCJ1ZHQCdGGEG
jDPD1HuEglSG4+z5QIBS/h4=
=C72n
-END PGP SIGNATURE-

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>> nope. the function jack_rechain_graph() rearranges the FIFO's that
>> connect each client, so that what karl described happens. in the above
>> code, the JACK server writes to the first fd in the chain, then waits
>> for either a read on the last fd, or a timeout. the "subchain" could
>> have involved a dozen clients while the server stays asleep.
>
>ok, may this be then qualified by the phrase "really cool"? must we
>resort to expletives to describe how cool this is? :-))

heh. this is what you get for being a linux audio developer who once
worked in a CS department (*). my first job there was maintaining a
C++ user level thread package called Presto. despite have no
background in threads, it immediately struck me as ridiculous (once i
understand what a context switch was) that in Presto, you always
switched back to the scheduler thread when moving between threads,
even there was an explicit handoff. some things you just never forget :)

of course, then i discovered that the hack someone had made to cfront
(the original C++ compiler) to support the per-thread variable keyword
"private" wasn't working, and so i had to learn about compilers next :)

--p

(*) which is also, by side effect, how i know bit more about the
history of gstreamer than i should :)

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>How would this system scale to a system with multiple processors?  Can
>it scale?
>
>If I understand this correctly, this system is doing a form of
>cooperative multitasking... with the Jack server making sure
>everything is going OK.  But, it seems that only one of these
>audio processes is running at a time.  And thus, you would be
>taking advantage of a multiprocessor system.  (Or am I missing
>something?)

no, you're not missing anything.

its entirely an internal implementation detail of any given JACK
server how it does this stuff. the API says *nothing* about it.

or then again, maybe you are ...

lets get a couple of things straight: this system is not useful for
operation over a network, because its goals are *low latency*. round
trips to adjacent machines don't fit into that scheme. so we're
talking only about SMP machines, not clusters. there are other systems
for network audio; none of the one's i've read about do low latency
well, if at all.

now, when it comes to SMP machines, for 99.9% of interested parties,
we're talking about dual processors. on such machines, its highly
advantageous to leave one processor free for a UI work. and i do mean
*highly* advantageous :) of course, i'm a known fan of "chromed" GUIs,
so thats just MHO.

next, we're talking audio data here for the most part, in which
parallel computation is only possible to the extent that there are
completely independent sub-streams - the temporal dependence of later
data on earlier data prohibits the kind of parallelization you can do
in, say, N-body problems.

as a result of these observations, i decided in my trial
implementation of the API to avoid the potentially large complexities
of running multiple audio threads. all clients are run in a single
series chain.

i know that gstreamer (and perhaps GLAME too) appear to have worked
these issues out. if so, thats great, and i hope that their designs
can be incorporated into jackd at some point, so that (1) if there are
independent substreams and (2) there are more than 2 processors then
it could support multiple audio threads. there are some vague ideas
present in the existing code base that point in this direction.

but please remember: this is completely invisible from an API
perspective: clients provide their callbacks, their callbacks get run
at the right time, and thats it.

--p

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Andy Wingo]

On Wed, 14 Nov 2001, Paul Davis wrote:
> nope. the function jack_rechain_graph() rearranges the FIFO's that
> connect each client, so that what karl described happens. in the above
> code, the JACK server writes to the first fd in the chain, then waits
> for either a read on the last fd, or a timeout. the "subchain" could
> have involved a dozen clients while the server stays asleep.

ok, may this be then qualified by the phrase "really cool"? must we
resort to expletives to describe how cool this is? :-))

thanks for clearing that up, that's really interesting.

wingo.

[linux-audio-dev] [ot] linuxdj.com problems... any traces of benno senoner ?

[Jörn Nettingsmeier]

sorry for the noise, but has anyone been in contact lately with
benno senoner ?

he's not been responding to mail for quite a while now, and there
are urgent problems with the linuxdj.com machine, which he
apparently owns.

i've been using [EMAIL PROTECTED] to reach him. does anyone know an
alternative address of his ?

please respond off-list. thanks.

jörn

-- 
Jörn Nettingsmeier 
home://Kurfürstenstr.49.45138.Essen.Germany  
phone://+49.201.491621
http://spunk.dnsalias.org
http://www.linuxdj.com/audio/lad/

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Charles Iliya Krempeaux]

Hello,

On Wed, 2001-11-14 at 10:52, Paul Davis wrote:
> >If I understand correctly, by reading the source and arguing with paul
> >:), the loop goes like this: well, actually, just the relevant part of
> >engine.c (this is from the old tarball, i haven't checked out cvs yet):
> >
> >in the function jack_engine_process(), trimmed for brevity:
> >
> >write (client->subgraph_start_fd, &c, sizeof (c));
> >
> >pollfd[0].fd = client->subgraph_wait_fd;
> >pollfd[0].events = POLLIN|POLLERR|POLLHUP|POLLNVAL;
> >
> >poll (pollfd, 1, engine->driver->period_interval);
> >
> >read (client->subgraph_wait_fd, &c, sizeof (c));
> >
> >so, if i understand correctly, jackd actually does get woken up after
> >each process. that's also necessary, so that if a client takes too long
> >that it can be cut out.
> 
> nope. the function jack_rechain_graph() rearranges the FIFO's that
> connect each client, so that what karl described happens. in the above
> code, the JACK server writes to the first fd in the chain, then waits
> for either a read on the last fd, or a timeout. the "subchain" could
> have involved a dozen clients while the server stays asleep.

(I should say that I've only joined this list recently, so I wasn't here
when all the stuff that lead up to jack was discussed, but anyways...)

How would this system scale to a system with multiple processors?  Can
it scale?

If I understand this correctly, this system is doing a form of
cooperative multitasking... with the Jack server making sure
everything is going OK.  But, it seems that only one of these
audio processes is running at a time.  And thus, you would be
taking advantage of a multiprocessor system.  (Or am I missing
something?)

See ya

 Charles Iliya Krempeaux
 tnt @ linux.ca
 ckrempea @ alumni.sfu.ca

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>And from an ancient message by Paul on why alsa-lib wasn't enough:
>
>> Establishing connections: alsa-lib offers one model for this, based on the
>> shared memory IPC mechanisms. Such a solution cannot scale to setups with
>> lots of clients running at low latencies because of the overhead of
>> context switching and the associated memory/cache performance loss.

heh. self->shoot (self->foot). self->mouth.place (self->foot).

that was before i measured it. i was wrong, plain and simple. it costs
us (very rougly) about 50usecs per switch, depending on how much data
the client touches. this is a real cost, but its not unbearable,
especially given what it buys us (clients in their own VM space, with
their own GUI toolkits/models/whatever).

but no, it won't scale to *lots* of clients at low latencies, even
so. for that, things have to be in-process clients, which is much
harder for application writers.

--p

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>If I understand correctly, by reading the source and arguing with paul
>:), the loop goes like this: well, actually, just the relevant part of
>engine.c (this is from the old tarball, i haven't checked out cvs yet):
>
>in the function jack_engine_process(), trimmed for brevity:
>
>write (client->subgraph_start_fd, &c, sizeof (c));
>
>pollfd[0].fd = client->subgraph_wait_fd;
>pollfd[0].events = POLLIN|POLLERR|POLLHUP|POLLNVAL;
>
>poll (pollfd, 1, engine->driver->period_interval);
>
>read (client->subgraph_wait_fd, &c, sizeof (c));
>
>so, if i understand correctly, jackd actually does get woken up after
>each process. that's also necessary, so that if a client takes too long
>that it can be cut out.

nope. the function jack_rechain_graph() rearranges the FIFO's that
connect each client, so that what karl described happens. in the above
code, the JACK server writes to the first fd in the chain, then waits
for either a read on the last fd, or a timeout. the "subchain" could
have involved a dozen clients while the server stays asleep.

--p

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Paul Davis]

>I'm trying to understand how JACK minimizes the number of context switches
>when the clients are out-of-process; if I got this right, this is one of
>the cool things it does (if it didn't, we would be able to run only a very
>small number of concurrent realtime out-of-process audio apps).

karl answered this earlier, perfectly correctly. note that it wouldn't
have a huge effect on system capabilities to swap back to the server
each time, but it would definitely be an extra load that we want to
minimize. 

>(since it keeps pointers to these functions).  Well, do these process()
>functions run inside the server address space (that is, are they part of
>the server process, run just like any other server function)? 

for an out-of-process client, process() runs in the client VM space,
but in a dedicated thread.

>Getting more practical: suppose one of the nodes is a wave file player;
>the "real" application has a thread that reads the disk data.  How do this
>data get to the process() function, since the process() function shouldn't
>block and, therefore, can't read the disk by itself?

the rest of the application has to move data to/from a (preferably
lock-free) ringbuffer (or similar); the JACK thread created by libjack
that executes process() simply pulls data from there.

note: there is nothing to stop you from *trying* to do disk i/o in the
process() callback, but the JACK server will probably cut you out of
the processing chain and/or stop the entire chain if you do, because
it will likely lead to timing overruns.

--p

[linux-audio-dev] Re: jack failure

[Paul Davis]

In message <[EMAIL PROTECTED]>you write:
>jackd fails:
>
># jackd -d hw:0 -r 44100 -p 1024
>creating alsa driver ... hw:0|1024|44100
>cannot connect to jack server
>cannot connect to jack server
>ALSA: cannot become client
>start engine ...
>engine driver not set; cannot start
>cannot join with audio thread (thread no longer exists)

try: rm -rf /tmp/jack* and then run it again.

this is a stupid issue that has be fixed very soon.

--p

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Nelson Posse Lago]

On Wed, Nov 14 2001 at 10:49:39am -0500, Andy Wingo wrote:

> [...] if data is read the callback is called, with a straight-up
> function call. so no jumps are used in that sense.

But the point is that data is read/written at every tick, which means
every jack client must be run inside every tick; that is, if a tick is 3ms
long and you have 10 clients running, you must have 10 context switches at
every 3ms; I believe this is exactly what JACK tries to avoid; if it
wasn't so, to have low latency you'd have to sacrifice a *lot* of
processing power. From the LAAGA draft documentation (
http://www.eca.cx/laaga/spec/index.html ):

> Let's say that we have 5 processes producing audio, and one of them
> handles the audio hardware i/o. Now to avoid buffer underruns, during one
> hardware interrupt cycle, all 5 processes must have enough processor time
> to produce the next block of audio data. The more processes are involved,
> the higher the process switching overhead becomes.
> [...]
> One way to avoid the possible IPC troubles is to locate all audio
> producing code into the audio engine process (audio engine refers to the
> process, or more specifically the thread, responsible for audio hardware
> i/o). In other words audio producers/consumers (=clients) are loaded as
> plugins to the engine (=server). But this approach, too, has its problems.
> 
> The biggest problem of this approach is the increased client side
> complexity. Client applications must be divided into realtime critical
> (audio producing/consuming) and non-realtime parts (user interfaces,
> network and file i/o, etc). The critical parts are loaded to the server
> process as plugins, while the non-critical part run in a separate lower
> priority process. Some kind of IPC is also needed between the realtime and
> non-realtime parts of the client. And to make things even more difficult,
> care must be taken that this communication never blocks the realtime
> critical process.

And from an ancient message by Paul on why alsa-lib wasn't enough:

> Establishing connections: alsa-lib offers one model for this, based on the
> shared memory IPC mechanisms. Such a solution cannot scale to setups with
> lots of clients running at low latencies because of the overhead of
> context switching and the associated memory/cache performance loss.

So, it seems to me things are a little more complicated than that...

See ya,
Nelson

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Andy Wingo]

On Wed, 14 Nov 2001, Karl MacMillan wrote:

> By having each client directly call the next client (by writing to the pipe) 
> instead of having the server (jackd) call each client in turn there are less 
> context switches - i.e. the server process is woken up less times.
> 
> Karl

If I understand correctly, by reading the source and arguing with paul
:), the loop goes like this: well, actually, just the relevant part of
engine.c (this is from the old tarball, i haven't checked out cvs yet):

in the function jack_engine_process(), trimmed for brevity:

write (client->subgraph_start_fd, &c, sizeof (c));

pollfd[0].fd = client->subgraph_wait_fd;
pollfd[0].events = POLLIN|POLLERR|POLLHUP|POLLNVAL;

poll (pollfd, 1, engine->driver->period_interval);

read (client->subgraph_wait_fd, &c, sizeof (c));

so, if i understand correctly, jackd actually does get woken up after
each process. that's also necessary, so that if a client takes too long
that it can be cut out.

regards,

wingo.

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Karl MacMillan]

On Wednesday 14 November 2001 10:49, Andy Wingo wrote:

> > OTOH, if the process() function is not run inside the server, but as a
> > thread of the "main" app, how does this save any context switches?
>
> One other thing I forgot to mention is that the shm memory is only valid
> after you receive the 'data ready' signal (i.e., after you can read from
> the second fd). Then, once you're done with it, you write on the same fd
> to tell the server you're done.
>
> This is all very implementation-side, so most app writers should not have
> to worry about this. but to summarize, process() gets called between
> libjack wakes you up from the poll() and before libjack writes on that
> fd.
>
> now, how this reduces context switches, I don't really know ;) could be
> something about how poll is implemented, i'll admit my ignorance on this
> one.
>

By having each client directly call the next client (by writing to the pipe) 
instead of having the server (jackd) call each client in turn there are less 
context switches - i.e. the server process is woken up less times.

Karl

> cheers,
>
> wingo.

Re: [linux-audio-dev] Simple question on JACK and callbacks

[Andy Wingo]

Hi Nelson,

> At each tick, JACK "calls back" on the process() functions of all the
> registered nodes, right? That is, it "jumps" to each of those functions
> (since it keeps pointers to these functions).  Well, do these process()
> functions run inside the server address space (that is, are they part of
> the server process, run just like any other server function)? If so, how
> do they do their work (that is, how do they access the data they need)?
> And, if so, shouldn't this be called "in-process"?

Well, as far as I've been able to undersand, the implementation of jack
goes like this:

you have two things, the jack server (call it jackd) and the jack lib
that your app links to (call it libjack)

when you start your app, libjack looks for a running jackd. if jackd is
not running it quits. so you need to have run jackd ;)

then, one shm segment and two pipes are set up between libjack and
jackd. the shm segment is for the audio data. the first pipe is for
'events' (like graph reordering). the second is to notify that data is
ready. when you do jack_run (or whatever that function's called, i don't
recall myself) it sets up a thread that polls on those two fd's. if data
is read the callback is called, with a straight-up function call. so no
jumps are used in that sense.

> Getting more practical: suppose one of the nodes is a wave file player;
> the "real" application has a thread that reads the disk data.  How do this
> data get to the process() function, since the process() function shouldn't
> block and, therefore, can't read the disk by itself?

You need to have grabbed it already in another thread.

> OTOH, if the process() function is not run inside the server, but as a
> thread of the "main" app, how does this save any context switches?

One other thing I forgot to mention is that the shm memory is only valid
after you receive the 'data ready' signal (i.e., after you can read from
the second fd). Then, once you're done with it, you write on the same fd
to tell the server you're done.

This is all very implementation-side, so most app writers should not have
to worry about this. but to summarize, process() gets called between
libjack wakes you up from the poll() and before libjack writes on that
fd.

now, how this reduces context switches, I don't really know ;) could be
something about how poll is implemented, i'll admit my ignorance on this
one.

cheers,

wingo.

Re: [linux-audio-dev] Re: more bad low latency results

[Tim Goetze]

>I did not get any reaction on one of my previous mails, so I send it
>again. There have been numerous reports on this list about good LL,
>and now I find it very frustrating I can not get it myself. Please
>help me out! I'd really hate the get the impression that the whole
>LL issue is still unreal.

i'm not running any latency test programs, but the scheduling and alsa
driver latency on this system (k6-III-450, audiophile 24/96, dma-ide) 
is low enough to allow me to do stereo software audio-through (read
samples from pcm capture, write them to pcm playback) with an audio cycle
time of 64 frames at 48 kHz. this means the pcm poll loop cycles reliably
at about 750 Hz (~1.3 ms between cycles).

kernels supporting this for me are 2.4.5-ll, 2.4.13-pe, 2.4.13-ll - all 
of these compiled for k6 - and currently 2.4.13-ll compiled for a 386. if
there are differences between mmx and not, they are too small to be
noticeable.

there are some stress situations that can cause xruns at 64 frames/cycle
with the current kernel, for example when cron.daily runs updatedb(1) or
find(1), but since these situations are predictable and avoidable i get
along. of course that's not to say i wouldn't like to run even less
frames/cycle with absolute stability - we're just not yet there it seems.

tim

RE: [linux-audio-dev] Project XEMO, MusicXML

[Karl MacMillan]

>From a quick look at the web page, it looks like the XML "standard" is not
supported by Finale, but rather there is a convertor from MusicXML to Finale
(quite a big difference - I don't think that Coda has signed onto this
format). I have seen at least a dozen XML formats for symbolic music
representation over the last two years and they have all been either
incomplete or just not caught on. This is a harder problem than it seems at
first. Supporting basic music notation is fairly straightforward, but
providing all of the functionality to support complex, modern notation is
difficult. See Guido for a format that does a good job at the harder parts
of notation - http://www.informatik.tu-darmstadt.de/AFS/CM/GUIDO/ - and my
project for an application that uses it - http://mambo.peabody.jhu.edu/omr/.

Karl

Karl MacMillan
Computer Music Department
Peabody Institute of Johns Hopkins University
[EMAIL PROTECTED] | 410-659-4440
mambo.peabody.jhu.edu/~karlmac

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Goetze
Sent: Wednesday, November 14, 2001 12:08 AM
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] Project XEMO, MusicXML


>thought y'all should know about this:
>
>   http://www.xemo.org/
>
>its an open-source, java based (western) music notation/composition
>program. they seem to have their hearts in the right place(s). runs on
>linux, windows and macos. uses netbeans and a new open XML "standard"
>for music notation also supported by finale:

wow. thanks for pointing to this.

tim

Re: [linux-audio-dev] Re: more bad low latency results

[Luke Tindall]

On Wednesday 14 November 2001 12:20, you wrote:
> I made a webpage with the several tests I did. Please have a look
> at it. I ran tune_disk /dev/hda, and
>
> do_tests none 3 256 0 2048
> (indeed a really small size for the disk i/o test, but I was more
> interested in the rest)
>
> http://193.145.55.36/latencytest
>
> The soundcard I use is a Trident 4DWave NX, drivers are latest alsa .
>
> First of all, it is really strange that
> 2.4.10-NO-LL-386
> 2.4.10-LL-386
> are practically identical; it is as if the low latency patch is not
> working. Maybe I missed something here, but if cat
> /proc/sys/kernel/lowlatency gives me 1, I can be sure it is on, isn't it?
>
> The 2.4.14-LL-PIII test have bad disk results (ran with large size btw). No
> idea why. How do I solve that?
>
> The best results seem to be the 2.4.14-LL-386, but here the
> alsa-lib/test/latency gives me underruns,
> ./latency -r 44100 -m 512 -M 512 -t 1 -p
> XRUNs right away.
> ./latency -r 44100 -m 1024 -M 1024 -t 1 -p
> does work but - and this is very important - the sound get fucked up
> (dusty vinyl record effect). I can record this and make a soundfile
> available for download if anybody is interested.
>
> Maarten

Try setting the sample rate to 48000, my trident sounds crap at 44100 
especially for recording, I've given up on 44100 and 48k is better. Are you 
changing the settings for /proc/sys/vm/bdflush? I'm following you progress 
closely as I have an athlon as well. 

-- 
Luke Tindall

Re: [linux-audio-dev] Re: more bad low latency results

[Takashi Iwai]

Hi,

At Wed, 14 Nov 2001 11:40:35 +0100,
Maarten de Boer wrote:
> 
> I did not get any reaction on one of my previous mails, so I send it
> again. There have been numerous reports on this list about good LL,
> and now I find it very frustrating I can not get it myself. Please
> help me out! I'd really hate the get the impression that the whole
> LL issue is still unreal.
> 
> > Since with AMD Athlon I get either bad low latency (compiling for AMD)
> > or bad sound quality (if I compile for 386. really don't understand why..),
> > I now did some tests on a Pentium III. The results are still not good:
> > 
> > kernel 2.4.14 low latency patch a Pentium III 800 Mhz, 
> > 
> > http://193.145.55.36/latencytest/2.4.14-LL-PIII/3x256.html
> > 
> > I am getting really disappointed. It's no fun to compile
> > kernels and alsa with different configurations lots of time only
> > to get bad results.
> > 
> > What kernels are you guys running? What would be the safest bet?
> > On what processor? I really want it to work well on the AMD Athlon.
> > Anybody using an AMD Athlon and has good LL results?

Hmm, I'm using an Athlon 600 MHz and got promising results even with
it.  You can find the results (on different conditions) under
http://alsa-project.org/~iwai/latency-results/2.4.12
The result with all LL-patches is found in ll-all directory.

The kernel was based on SuSE's 2.4.12, which is mostly equivalent with
AA-patch.  FS is reiserfs.  Compiled with ARCH_M586.

The tests were harder than normal cases, since I ran find / in
background together with the normal stress tests.

I guess Andrew's LL patch misses resched checks in two long loops with
lru lock in fs/buffer.c.  One is like this:


--- linux-2.4.13.SuSE/fs/buffer.c   Mon Oct 29 14:13:58 2001
+++ linux-2.4.13.SuSE+LL/fs/buffer.cWed Oct 31 16:03:22 2001
@@ -259,7 +259,11 @@ static int wait_for_buffers(kdev_t dev, 
while (next && --nr >= 0) {
struct buffer_head *bh = next;
next = bh->b_next_free;
-
+   if (conditional_schedule_needed()) {
+   spin_unlock(&lru_list_lock);
+   unconditional_schedule();
+   return -EAGAIN;
+   }
if (!buffer_locked(bh)) {
if (refile)
__refile_buffer(bh);


and more checks are already included in Andrea's tree.
I'm not sure vanilla 2.4.14 has it (perhaps not?).  Here goes:


diff -urN 2.4.13pre3/fs/buffer.c sched/fs/buffer.c
--- 2.4.13pre3/fs/buffer.c  Tue Oct 16 02:03:44 2001
+++ sched/fs/buffer.c   Wed Oct 17 23:40:56 2001
@@ -231,6 +231,7 @@
 static void write_unlocked_buffers(kdev_t dev)
 {
do {
+   conditional_schedule();
spin_lock(&lru_list_lock);
} while (write_some_buffers(dev));
run_task_queue(&tq_disk);
@@ -280,6 +281,7 @@
 static int wait_for_locked_buffers(kdev_t dev, int index, int refile)
 {
do {
+   conditional_schedule();
spin_lock(&lru_list_lock);
} while (wait_for_buffers(dev, index, refile));
return 0;



Takashi

[linux-audio-dev] jack failure

[Maarten de Boer]

jackd fails:

# jackd -d hw:0 -r 44100 -p 1024
creating alsa driver ... hw:0|1024|44100
cannot connect to jack server
cannot connect to jack server
ALSA: cannot become client
start engine ...
engine driver not set; cannot start
cannot join with audio thread (thread no longer exists)

Maarten

[linux-audio-dev] jackd

[Maarten de Boer]

Hello,

When trying to run jack, I got the following error:

jackd: error in loading shared libraries: jackd: undefined symbol: mknod

This was easily solved adding #include  in engine.c

Also, to compile the fltk client, I had to change the order of 
arguments: move the object file to the front, changing

c++ -g -Wall -D_REENTRANT -I/usr/include/glib-1.2 -I/usr/lib/glib/include -o 
jack_fltk_client -L. -L/usr/X11R6/lib -lfltk -lX11 -lXext -ljack -lltdl -lpthread 
fltk_client.o -L/usr/lib -lglib

to:

c++ -g -Wall -D_REENTRANT  fltk_client.o -I/usr/include/glib-1.2 
-I/usr/lib/glib/include -o jack_fltk_client -L. -L/usr/X11R6/lib -lfltk -lX11 -lXext 
-ljack -lltdl -lpthread -L/usr/lib -lglib

Maarten

[linux-audio-dev] Re: more bad low latency results

[Maarten de Boer]

I made a webpage with the several tests I did. Please have a look
at it. I ran tune_disk /dev/hda, and

do_tests none 3 256 0 2048
(indeed a really small size for the disk i/o test, but I was more
interested in the rest)

http://193.145.55.36/latencytest

The soundcard I use is a Trident 4DWave NX, drivers are latest alsa .

First of all, it is really strange that 
2.4.10-NO-LL-386
2.4.10-LL-386
are practically identical; it is as if the low latency patch is not
working. Maybe I missed something here, but if cat /proc/sys/kernel/lowlatency
gives me 1, I can be sure it is on, isn't it?

The 2.4.14-LL-PIII test have bad disk results (ran with large size btw). No
idea why. How do I solve that?

The best results seem to be the 2.4.14-LL-386, but here the alsa-lib/test/latency
gives me underruns, 
./latency -r 44100 -m 512 -M 512 -t 1 -p
XRUNs right away. 
./latency -r 44100 -m 1024 -M 1024 -t 1 -p
does work but - and this is very important - the sound get fucked up
(dusty vinyl record effect). I can record this and make a soundfile
available for download if anybody is interested.

Maarten

[linux-audio-dev] Compiling LL kernel for AMD without 3DNOW

[Maarten de Boer]

Hello,

In reply to D. Stimits and Roger Larsson about compiling
an LL kernel for AMD Athlon without the 3DNOW optimizations

I still get the undefined references to the 
*_mmx_* functions. I am perfectly sure that I really recompiled
it all, and to demonstrate it, here follow the steps I toke:

I try it with a freshly unpacked kernel, as follows:

$ rm -rf linux
$ rm -rf linux-2.4.10-LL/
$ tar xIf linux-2.4.10.tar.bz2
$ mv linux linux-2.4.10-LL  
$ ln -s linux-2.4.10-LL linux
$ cd linux
$ patch -p1 < ../2.4.10-low-latency.patch
$ make xconfig

I set my Processor Family to Athlon/Duron/K7, turn of
SMP (why is that set by default?), turn on low latency
and low latency sys ctl, configure my SCSI and Ethernet
drivers to be compiled as modules, and leave the rest
of the options at their defaults.

I now edit my .config, commenting out the line, changing
CONFIG_X86_USE_3DNOW=y
to
# CONFIG_X86_USE_3DNOW is not set

I edit the top Makefile, setting
EXTRAVERSION = -LL-AMD-NO3DNOW

and I compile with
$ make dep
$ make

and get the undefined references!!

Now, I try what Dave suggests:

$ cp .config ../2.4.10-config
$ make mrproper
$ cp ../2.4.10-config .config
$ make oldconfig
$ make dep
$ make

and _AGAIN_ I get the undefined references.

So I am really wondering now: what am I doing different? I mean
you _did_ indeed compile the kernel for AMD without 3DNOW, did you?

Maarten

[linux-audio-dev] Re: more bad low latency results

[Maarten de Boer]

I did not get any reaction on one of my previous mails, so I send it
again. There have been numerous reports on this list about good LL,
and now I find it very frustrating I can not get it myself. Please
help me out! I'd really hate the get the impression that the whole
LL issue is still unreal.

> Since with AMD Athlon I get either bad low latency (compiling for AMD)
> or bad sound quality (if I compile for 386. really don't understand why..),
> I now did some tests on a Pentium III. The results are still not good:
> 
> kernel 2.4.14 low latency patch a Pentium III 800 Mhz, 
> 
> http://193.145.55.36/latencytest/2.4.14-LL-PIII/3x256.html
> 
> I am getting really disappointed. It's no fun to compile
> kernels and alsa with different configurations lots of time only
> to get bad results.
> 
> What kernels are you guys running? What would be the safest bet?
> On what processor? I really want it to work well on the AMD Athlon.
> Anybody using an AMD Athlon and has good LL results?

Re: [linux-audio-dev] more bad low latency results

[Maarten de Boer]

On Tue, 13 Nov 2001 14:40:42 -0600
Christopher Deckard <[EMAIL PROTECTED]> wrote:

> i'm getting ~8ms on an AMD K6 running 2.2.17 LL under RH6.1, and using
> uncsound 4.x.

that's not <3ms either...

Maarten

Re: [linux-audio-dev] shared memory problems

[Richard Guenther]

On Tue, 13 Nov 2001, Paul Davis wrote:

> >> i wish there was a way force certain things to happen when a process
> >> dies on SIGKILL, though. we can't call shmctl(id,IPC_RMID) on shm
> >> segments until we know that no more clients will attempt to connect -
> >> i.e. the server is exiting (because a "marked-destroyed" segment
> >> cannot be accessed by a new task). thus, i defer this via
> >> on_exit(). alas, these are not called if it dies with SIGKILL, and we
> >> end up with "persistent" shm segments. sigh. at least i can handle all
> >> other signals properly.
> >
> >Well, its easy to do this. Just have the server do a fork() early at
> >startup time, have the new process be the server and the parent just
> >waiting on the server and doing necessary cleanup. Just like X does
> >with Xwrapper.
>
> sounds great. except that also means defining some IPC protocol so
> that the server can tell the wrapper about shm resources and files
> that need to be released, right? they're not in the same address
> space.

Well, either allocate all resources before fork() (if possible), or
have a resource list in a shm region allocated before fork(). Something
along this should be the simplest (rather than setting up another
comm via sockets or the like).

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/