Re: [linux-audio-dev] memory management

[Josh Green]

On Mon, 2001-11-26 at 20:01, Paul Davis wrote:
> >So really, now that I think about it, it probably wouldn't be MUCH more
> >complicated than a simple EXEC on Smurf's part. It would be nice if
> >sample editors implemented same session loading of multiple samples from
> >the command line though (maybe some editor already has this?).
> >For things like batch sample operations and such I could have an option
> >to export all the sample data to individual wave files in a directory
> >where editing could take place and then re-imported back.
> 
> snd will do all this (and more).
> 
> --p

Cool, I'll take a look at it.

-- 
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Paul Davis]

>The scopes are also looking better (gtk+ interface plugin). There were also

the gtk interface plugin doesn't load for me.

Loading Interface plugin: GTK+ interface v1.0
alsaplayer: error in loading shared libraries:
/usr/local/lib/alsaplayer/interface/libgtk.so: undefined symbol:
 length__t18string_char_traits1ZcPCc

which of course c++filt clarifies as:

  string_char_traits::length(char const *)

--p

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Paul Davis]

>I'm getting very poor performance from jackd. Even on my, somewhat
>beefy, 1.33MHZ Athlon box I get horrible xruns from 10ms up to 150ms.
>Anything below 512 frames per interrupt is unworkable. As soon as I connect

OK, i just tried it on my dual PII450 box, with

jackd -d trident -R -p 64
jackplayer -i text some.wav

and got no xruns at all. this is on 2.4.0+lowish.

there is definitely some clipping or other wierd effect occuring with
"jackplayer". it is present even when jackplayer is the only client,
but then just gets worse when other clients connect and use the same
port. this is odd, since they have no input. when i run them with
input, but without jackplayer, the effect is not present. 

the effect is strange. its not like harsh clipping. its a strange kind
of constant buzzing, but its definitely like clipping in that its
clearly signal level related. i sort of suspect an issue with the
sample_move_dS_s16 function that you borrowed. 

but as i said, its notable that its in place even without any other
clients, but not with other clients without jackplayer, so i sort of
suspect something inside jackplayer.

>connecting jack_simple_client. Running with "default|128|44100" will
>happily xrun every bdflush :-/ .. I'm using an UW2 SCSI disk

i hate to say this, but this sounds like 1 of only 2 possibilities:

  * kernel issues
  * uniprocessor issues

also, i note that your code is burning a *LOT* of CPU time. the
"jack_simple_client", which copies 1 channel from input to output,
almost doesn't register in xosview (jackd is invisible). jackplayer
with a text interface is burning chunks of CPU comparable to what
ardour uses for 8-16 tracks of highly non-contiguous audio plus a GUI,
sometimes even more.

--p

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Paul Davis]

i don't to be able to compile alsaplayer. you seem to have
hard-coded the paths to glib in the configure file (this is from
configure itself):

CFLAGS="$CFLAGS -I$x_includes -L$x_libraries"
CPPFLAGS="$CPPFLAGS -I$x_includes -I/usr/include/glib-1.2 -I/usr/lib/glib/include 
-I/usr/local/jack/include"
AS="$CC"

mine is in /usr/local, not /usr. i tried --with-glib-prefix and
--with-glib-exec-prefix, but neither of them change the CXXFLAGS
setting that results in:

g++ -DHAVE_CONFIG_H -I. -I. -I..  -I/usr/X11R6/include
-I/usr/include/glib-1.2 -I/usr/lib/glib/include 

these paths are not valid on my system. configure appears to use
glib-config, 

  checking for glib-config... /usr/local/bin/glib-config
  checking for GLIB - version >= 1.2.8... yes

but glib-config says:

% glib-config --cflags
-I/usr/local/lib/glib/include -I/usr/local/include

compare with the output above. i've hacked the configure script for now.

---


>andy@phobos:/usr/local/jack/bin$ ./jackd -d hw:0,0
>creating alsa driver ... hw:0,0|64|48000
>ALSA lib conf.c:3218:(parse_args) Unknown parameter 1
>ALSA lib conf.c:3326:(snd_config_expand) Parse arguments error: No such
>file or directory
>ALSA lib control.c:570:(snd_ctl_open_noupdate) Invalid CTL hw:0,0
>control open "hw:0,0" (No such file or directory)
>cannot load ALSA driver module
>
>Hmm, no ctl device for hw:0,0 ?? I'll dig into alsa_driver to see
>where/why it fails.

I wonder if ALSA has been changed to no longer support hw:N,M ?

>Okay, is jackd doing clipping? I.e. does it ensure that output stays
>between 1.000 and -1.000 ? All hell breaks loose when I connect multiple

Nope. How and why could it do that? AFAIK, there are only a few ways
to handle mixing:

   1) take no action: the sum may or may not clip
   2) clip the result
   3) implicitly clip in the conversion back to h/w format
   4) use compression on the signal
   5) scale each input by a constant amount
   6) apply independent gain control to each input

i don't consider any of these except (1) as something that JACK would
do. do you feel different?

>clients to the same ports here. Garbled output, and probably some memory
>overwrites since jackd usually segfaults after 3 or 4 connects. 

thats nothing to do with multiple ports, i believe. 

Re: [linux-audio-dev] question regarding enabling libpthread in theconfigure

[Josh Green]

On Mon, 2001-11-26 at 17:11, Ivica Bukvic wrote:
> Hi all, does anyone know what is the Linux configure's flag for enabling
> libpthread, so that my resulting makefile has LIBPTHREAD =
> /libpthread.a? I am using Kdevelop and it has
> configure implemented as a part of the project and the creates
> Makefile.am, .in and eventually Makefile itself, so storing this kind of
> info in those files would only result in a temporary fix.
> 
> I've tried ./configure --enable-libpthread  or --enable--lpthread etc.
> and none worked. My line in Makefile still reads LIBPTHREAD =
> @LIBPTHREAD@ and unless I hack it myself after the ./configure has been
> done, it fails to compile the app. Any help would be greatly
> appreciated! Sincerely,
> 
> Ivica Bukvic
> 

The file you want to edit is "configure.in" which is what autoconf uses
to generate the configure script. You probably want to add something
like:

AC_CHECK_LIB(pthread, pthread_create)

This will add -lpthread to LIBS and define HAVE_LIBPTHREAD.
See "info autoconf" more more information, as I have never actually
added pthread support to a program :)

-- 
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)

Re: [linux-audio-dev] memory management

[Paul Davis]

>So really, now that I think about it, it probably wouldn't be MUCH more
>complicated than a simple EXEC on Smurf's part. It would be nice if
>sample editors implemented same session loading of multiple samples from
>the command line though (maybe some editor already has this?).
>For things like batch sample operations and such I could have an option
>to export all the sample data to individual wave files in a directory
>where editing could take place and then re-imported back.

snd will do all this (and more).

--p

Re: [linux-audio-dev] memory management

[Josh Green]

On Mon, 2001-11-26 at 13:12, Paul Davis wrote:
> >
> >i do not understand. say i'm making a sw clone of the korg es-1
> >'rhythm production sampler'. i need to edit the samples somehow, and
> >then later apply some effects probably. what is the set of operations
> >that i would want an editor to perform on the sample? (i don't know a
> >better term than 'sample' here; perhaps i'll call it a clip.)
> >
> >- read in from a file
> >- write to a file
> 
> if thats all you want to do, then use can use the time-honored unix
> API's: fork(2) and exec(2).
> 

Perhaps I should define more specifically what I would like to do with
my particular app, Smurf Sound Font Editor.

1. Active setting of loop points in a sample. So you can listen while
you set them.

2. A convenient method to edit a sample in a sound font with the user's
favorite editor (MONO or STEREO 16 bit samples)

The first item I think I will just implement in Smurf, as there is no
guarantee that another editor will have this kind of functionality and
setting loop points is one of the most common tasks in making a sound
font.
For the second item, something slightly more sophisticated than EXEC'ing
an editor would be nice. With sound fonts we're dealing with fairly
small individual samples (a sound font bank could be in excess of 100MB
or more, but this is typically divided among thousands of samples). So
we can expect samples to usually be under lets say, throwing out a
figure, 8MB. This is why, currently, Smurf operates on samples entirely
in memory. Only one sample is in memory at a time though, for displaying
and editing (currently just cutting) purposes.
So Smurf doesn't really need to have concurrent access to the sample as
it is being edited (as long as the editor allows you to listen to it).

Here is what I see as the editing cycle:
1. Sample is selected in sound font tree
2. User clicks "EDIT" button
3. Sample is extracted from sound font (or wherever it resides) and
stored in a temporary file
4. Smurf spawns custom editor passing the temporary file name (via
command line arguments)
5. User does editing
6. User saves file in editor
7. Smurf is polling for change on file or perhaps user must manually
click an option to reload the edited sample

Since sound fonts deal with many samples, it is best to cut down on the
amount of time and steps it takes during the edit operation.
Ideally the editor should have some support for loading multiple samples
and the ability to load a specific file specified from the command line
(without spawning a new copy of the program).
The other part is getting the sample back into Smurf. I guess some sort
of timed polling of the stat of the file or something would work just
fine.
The other problem is if Smurf happens to be using the audio device (for
iiwusynth wavetable engine perhaps). This becomes a problem when the
user tries to listen to the edited sample in their editor. Not sure how
to deal with this one. Maybe streaming the audio data back to Smurf to
be played by whatever audio engine it is using, or perhaps I should
leave it up to the user to figure this out. Could jack be used for
something like this? (I think I asked this question before)

So really, now that I think about it, it probably wouldn't be MUCH more
complicated than a simple EXEC on Smurf's part. It would be nice if
sample editors implemented same session loading of multiple samples from
the command line though (maybe some editor already has this?).
For things like batch sample operations and such I could have an option
to export all the sample data to individual wave files in a directory
where editing could take place and then re-imported back.
Anyways, hope I haven't overwhelmed this list with my big email. I'll
try to write less :)

--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[John Lazzaro]

> > sufficient for what?

> Sufficient to not lock people out of their machine.

Sfront is more paranoid than this -- it uses signals to implement a 
watchdog timer which, if it goes off, relinquishes SCHED_FIFO. The
timer gets reset every time sfront returns from blocking I/O. This
catches the case of your program computing audio just "fast enough"
to avoid overruns, but not fast enough to cause blocking on audio
reads or writes. It also catches naive SAOL programmers who write
infinite loops ... 

See the code in sfront/src/lib/asys/linux.c for more details, search
for the SCHED_FIFO function primitives to see what's going on ...

-
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Andy Lo-A-Foe]

On Mon, Nov 26, 2001 at 07:47:21PM -0500, Paul Davis wrote:

> if they do not happen without a client, it doesn't have anything to do
> with the core code that handles ALSA etc.

Right. 

> that points to something something more like (a). i'll download
> alsaplayer tonight and try it out on my machine. that should provide
> some clues about what is and is not causing the problem.

I also increaed the fragment count to 3, from 2. Works better on UP I
think.

> one thing, however. can you try connecting to hw:0,0 and see what
> happens then? i doubt it will make a difference, but i'd be
> interested ...

andy@phobos:/usr/local/jack/bin$ ./jackd -d hw:0,0
creating alsa driver ... hw:0,0|64|48000
ALSA lib conf.c:3218:(parse_args) Unknown parameter 1
ALSA lib conf.c:3326:(snd_config_expand) Parse arguments error: No such
file or directory
ALSA lib control.c:570:(snd_ctl_open_noupdate) Invalid CTL hw:0,0
control open "hw:0,0" (No such file or directory)
cannot load ALSA driver module

Hmm, no ctl device for hw:0,0 ?? I'll dig into alsa_driver to see
where/why it fails.

> yep. any number can connect to the same port. if you run
> jack_simple_client twice, thats what's happening then, for
> example. both instances are outputting to the same ALSA output port.

Okay, is jackd doing clipping? I.e. does it ensure that output stays
between 1.000 and -1.000 ? All hell breaks loose when I connect multiple
clients to the same ports here. Garbled output, and probably some memory
overwrites since jackd usually segfaults after 3 or 4 connects. I'll do
some more debugging. 

Andy

[linux-audio-dev] question regarding enabling libpthread in the configure

[Ivica Bukvic]

Hi all, does anyone know what is the Linux configure's flag for enabling
libpthread, so that my resulting makefile has LIBPTHREAD =
/libpthread.a? I am using Kdevelop and it has
configure implemented as a part of the project and the creates
Makefile.am, .in and eventually Makefile itself, so storing this kind of
info in those files would only result in a temporary fix.

I've tried ./configure --enable-libpthread  or --enable--lpthread etc.
and none worked. My line in Makefile still reads LIBPTHREAD =
@LIBPTHREAD@ and unless I hack it myself after the ./configure has been
done, it fails to compile the app. Any help would be greatly
appreciated! Sincerely,

Ivica Bukvic

[linux-audio-dev] GSMP v0.0.2

[Rene Rebe]

Hi all.

I just uploaded GSMP v0.0.2. Because we had not much spare time in the last
weeks it is mainly a bug-fix release.

It includes:
- an OSS plugin (enabled via --oss on the command-line if ALSA is compiled, too)
- Mandrake compile fixes
- some gcc-3 and other bug-fixes
- new tone-generators (for testing)
- mp3 ist still eXPerimental (sometimes the data is still one mp3-frame out of
  sync) - but the seek is much faster ...

URL: http://www.tfh-berlin.de/~s712059/gsmp/index.html

Now we will focus on the next points from our roadmap: real overlay graphics,
rework the plugin / menu-system (incl. key-binding support), real marker
and envelope support.

If anyone would like to help in the project feel free to contact us. We would
be realy happy to get people who like graphic-UI-programming. HINT HINT ;-) Or
to contribute in any other area they like!

k33p h4ck1n6
  René Rebe

-- 
René Rebe (Registered Linux user: #127875 )

eMail:[EMAIL PROTECTED]
  [EMAIL PROTECTED]

Homepage: http://www.tfh-berlin.de/~s712059/index.html

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Paul Davis]

>> the build process and also added support for the JACK audio server.

excellent. thank you!

>I've only tested this with a modified jackd alsa_driver that does
>S16_LE, 2 channel, interleaved output. I can't test it on 24-bit
>hardware for now.
>
>I'm getting very poor performance from jackd. Even on my, somewhat
>beefy, 1.33MHZ Athlon box I get horrible xruns from 10ms up to 150ms.
>Anything below 512 frames per interrupt is unworkable. As soon as I connect
>to jackd the xruns start. 

this is key: they only start once alsaplayer is running. that means 1
of two things is causing the problem:

   a) the roundtrip between the server+client
   b) the code in the client

if they do not happen without a client, it doesn't have anything to do
with the core code that handles ALSA etc.

>most likely not my process() call since the same happens when
>connecting jack_simple_client. Running with "default|128|44100" will
>happily xrun every bdflush :-/ .. I'm using an UW2 SCSI disk

that points to something something more like (a). i'll download
alsaplayer tonight and try it out on my machine. that should provide
some clues about what is and is not causing the problem.

one thing, however. can you try connecting to hw:0,0 and see what
happens then? i doubt it will make a difference, but i'd be
interested ...

>I was also under the impression that one could connect multiple clients
>to the same Output port and have the data mixed automatically. Is this
>true? (I haven't read through all the jack code yet).

yep. any number can connect to the same port. if you run
jack_simple_client twice, thats what's happening then, for
example. both instances are outputting to the same ALSA output port.

i wish i could devote more time to working just on JACK. even so, now
that you've done alsaplayer and i've got rythmnlab, there is more
pressure on me to get ardour working too, and that should force more
effort from me on the jack code. thanks for your efforts in this arena.

--p

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Paul Davis]

>It sounds like SCHED_RR is a bit more polite. I wouldn't want a monster
>synthesis thread to hog the CPU and lock out everything else. I guess with
>Round Robin that equal priority threads at least get a chance to run. I want
>equal priority threads to timeslice with my task.

you understand that its "equal priority *and* SCHED_RR class", right?
normal SCHED_OTHER threads won't get run as long as there are any
runnable SCHED_RR or SCHED_FIFO threads ...

--p

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Andy Lo-A-Foe]

On Mon, Nov 26, 2001 at 03:25:10PM -0800, STEFFL, ERIK *Internet* (SBCSI) wrote:

>   just wondering - I tried alsaplayer yesterday (after long time) and I
> couldn't find any way to remotely control it from command line (something
> like xmms does - e.g. xmms -s will stop the currently playing xmms etc.).
> IIRC there was some sort of scripting supported in kde, is there anything

Yeah, I need to add a socket interface to do some remote controlling.
Luckily there is now an interface plugin API so this should be easy
enough. 

> similar in gnome (or more precisely gtk)? is anything like that planned?

GTK+ only provides GUI calls, remote controlling a program requires a custom
piece of code since there's no universal Linux/Unix scripting API. I'd
like to keep the core of the player GNOME/KDE free.

Anyway, alsaplayer-remote is high on my TODO list.

Andy

[linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Phil Burk]

THANKs to all who responded. The effect of bumping the priority was so
dramatic that I really need to do it. I now understand it enough to feel
safe about it.

> SCHED_RR is designed for situations where there are several
> "real time" kernel threads and you wish to ensure that they all get
> time on the processor, regardless of their own intentions. the RR
> stands for "round robin". SCHED_FIFO is different in that once a
> thread is running, it will run forever, or until it yields, blocks or
> a higher priority SCHED_FIFO thread is runnable.

It sounds like SCHED_RR is a bit more polite. I wouldn't want a monster
synthesis thread to hog the CPU and lock out everything else. I guess with
Round Robin that equal priority threads at least get a chance to run. I want
equal priority threads to timeslice with my task.

> >Q: I have code that throttles back if I consume too much CPU time. Is
that
> >sufficient?
> sufficient for what?

Sufficient to not lock people out of their machine.

> >Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
> >should I use less?
>
> its up to you. if you use the max value, its impossible for anyone to
> ever kill you if your thread gets stuck in a loop.

Maybe I'll use max-2 so others can get ahead of me and kick me out. (I saw a
bug report that threads with N+1 priority could not preempt priority N
threads. So I'll use max-2 instead of max-1).

Phil Burk

RE: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[STEFFL, ERIK *Internet* (SBCSI)]

> -Original Message-
> From: Andy Lo-A-Foe [mailto:[EMAIL PROTECTED]]
> 
> Howdy,
> 
> AlsaPlayer 0.99.52-cvs20011126-jack was released on the website,
> http://www.alsaplayer.org

  just wondering - I tried alsaplayer yesterday (after long time) and I
couldn't find any way to remotely control it from command line (something
like xmms does - e.g. xmms -s will stop the currently playing xmms etc.).
IIRC there was some sort of scripting supported in kde, is there anything
similar in gnome (or more precisely gtk)? is anything like that planned?

erik

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[dave willis]

On Mon, 26 Nov 2001, Phil Burk wrote:

> I have heard reports that SCHED_FIFO has several bugs. I have searched the
> web and read many posts about this but there are still unanswered questions.
>
> Q: Does SCHED_RR work better than SCHED_FIFO? Fewer bugs?

i just read that SCHED_FIFO was discovered broken in 2.4.15, but i use
2.4.12(-ac3-pe) and it works (as well as earlier 2.4 kernels).

i've read somewhere that SCHED_RR has more bugs than SCHED_FIFO.
does anyone know if other unixes can use SCHED_FIFO with non-superuser
privileges?

> Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
> should I use less?

i don't know much more than the sched_setscheduler man-page and my results
in using SCHED_FIFO, but the latencytest program uses
sched_get_priority_max(SCHED_FIFO) [ = 99 ], pd seems to use 98 for the
child and 96 for the parent, and jmax uses 96 for watchdog_low, 98 for
watchdog_high, and 97 for fts.

-dave
-- 
perl -e'@email=split(//,".tenmhd\@nosbud");foreach$letter(@email){$
email=$letter.$email;}$email=~s/(m|net\.)/a\1\1/g;print"$email\n";'

Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Andy Lo-A-Foe]

> the build process and also added support for the JACK audio server.

Some notes...

I've only tested this with a modified jackd alsa_driver that does
S16_LE, 2 channel, interleaved output. I can't test it on 24-bit
hardware for now.

I'm getting very poor performance from jackd. Even on my, somewhat
beefy, 1.33MHZ Athlon box I get horrible xruns from 10ms up to 150ms.
Anything below 512 frames per interrupt is unworkable. As soon as I connect
to jackd the xruns start. Running with -R -P 99 has no effect
(2.4.16-pre1 + low latency patches). The same code runs rock solid at 
256 x 3 fragments when outputting to alsa directly (blocked I/O). It is
most likely not my process() call since the same happens when
connecting jack_simple_client. Running with "default|128|44100" will
happily xrun every bdflush :-/ .. I'm using an UW2 SCSI disk

I was also under the impression that one could connect multiple clients
to the same Output port and have the data mixed automatically. Is this
true? (I haven't read through all the jack code yet).

Andy

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Andy Lo-A-Foe]

On Mon, Nov 26, 2001 at 04:52:01PM -0500, Ivica Bukvic wrote:

> absolutely nothing, even though the program compiles without errors. Is
> this due to fact that I need to run the app as a superuser? I am pretty

Yes, setting your thread to SCHED_FIFO/RR is a privileged operation
which only root can do. Either run as root, or make your program suid
root.

> sure that I do not need LL patches for this thing to run since pthreads
> have been designed to run on regular linux machines (please do correct
> me if I am wrong).

However LL patches help a lot if you want to do any low latency audio on
Linux.

Andy

[linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack

[Andy Lo-A-Foe]

Howdy,

AlsaPlayer 0.99.52-cvs20011126-jack was released on the website,
http://www.alsaplayer.org

This is really a pre-release for 0.99.52. I've made some more changes in
the build process and also added support for the JACK audio server.
The scopes are also looking better (gtk+ interface plugin). There were also
some changes made in the alsa-final output plugin. Most input plugins
are now reentrant which allows internal mixing of multiple music files.
The --crossfade option, when chosen, will do a crude crossover between
playlist entries. This is a proof of concept feature, a later release
will include full control of the crossfading, and it will actually fade :)

Most changes are internal, so if you are looking for advances in the
GUI/usability, not in this release.

Please test... Thank you!

http://www.alsaplayer.org/alsaplayer-0.99.52-cvs20011126-jack.tar.gz
http://www.alsaplayer.org/alsaplayer-0.99.52-cvs20011126-jack.tar.bz2

or

ftp://ftp.alsa-project.org/pub/people/andy/alsaplayer-0.99.52-cvs20011126-jack.tar.gz
ftp://ftp.alsa-project.org/pub/people/andy/alsaplayer-0.99.52-cvs20011126-jack.tar.bz2

Regards,
Andy

RE: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Ivica Bukvic]

Wow, exactly the topic I am stuck at. So, I guess I'll use this
opportunity to ask an additional question regarding this topic and that
is that in my application I am currently experimenting with SCHED_RR,
but every time I set the thread to run this way, the thread does
absolutely nothing, even though the program compiles without errors. Is
this due to fact that I need to run the app as a superuser? I am pretty
sure that I do not need LL patches for this thing to run since pthreads
have been designed to run on regular linux machines (please do correct
me if I am wrong).

I'd greatly appreciate any help on this issue! Sincerely,


Ivica Ico Bukvic, composer, audio sculptor, programmer & computer
consultant
http://meowing.ccm.uc.edu/~ico/
[EMAIL PROTECTED]

"To be is to do"   - Socrates
"To do is to be"   - Sartre
"Do be do be do"   - Sinatra
"I am" - God

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Phil Burk
Sent: Monday, November 26, 2001 2:11 PM
To: [EMAIL PROTECTED]
Subject: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

Hello,

I am working with a group on PortAudio, a simple cross-platform
open-source
audio API. We currently support Windows, Mac, BeOS, SGI, and, of course,
Unix.

Folks have been reporting audio glitches even with a buffer size
equivalent
to 100 msec. I have experimented with setting my thread priority to the
max
for SCHED_FIFO and that seems to eliminate the glitches. I can get down
to
around 5 or 10 msec latency on RedHat 7.2, even without any low-latency
patches. But I have to run as superuser.

I have heard reports that SCHED_FIFO has several bugs. I have searched
the
web and read many posts about this but there are still unanswered
questions.

Q: Do the SCHED_FIFO bugs prevent a simple use of sched_setscheduler()
to
bump the priority of a thread that is reading and writing to OSS? I want
the
code to work on old systems as well as new.

Q: Does SCHED_RR work better than SCHED_FIFO? Fewer bugs?

Q: I have code that throttles back if I consume too much CPU time. Is
that
sufficient?

Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
should I use less?

Thanks,
Phil Burk
JSyn,pForth,DSP,ASIC - http://www.softsynth.com
Portable Audio I/O   - http://www.portaudio.com
Interaction Server   - http://www.transjam.com

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Paul Davis]

>So, SCHED_FIFO wasn't always broken -- I haven't kept up
>with the details of how it broke under 2.4 and whether or
>not its truly fixed, but if your goal is to just get a 
>system up where SCHED_FIFO is known to work in order to
>do initial code debugging, 2.2.17 is known to work ...

it seems fine in 2.4.0 as well. or put another way, there is a
night-and-day difference between using it and not using it :)

--p

Re: [linux-audio-dev] memory management

[Paul Davis]

>I would be interested to know how this differs from schemes used by other
>editors, if anyone is willing to briefly explain. For example I have
>never heard of EDLs and I couldn't find a good explanation on the net.

ardour (almost) never modifies data on disk. all edits are done using
a playlist that consists of a list of time-ordered regions. each
region describes a starting point in an audio file and a duration.
all FX are applied in real time, or applied on a per-region basis, and
written back to disk in a new audio file. all temporal-based edits
just consist of modifying region definitions and playlist composition.

this is consistent with the way that most DAWs operate.

an EDL is an "Edit Decision List", and just consists, bizarrely
enough, of a list of editing decisions made by the user. There are,
however, two ways to store an EDL. one way is as the list of edits
themselves:

cut from X to Y
insert foo at N

and so on. the other way is to store the result, which is typically
called a playlist in many programs:

   at time N: file foo, start at sample M, continue for O samples
   at time P: file bar, start at sample T, continue for R samples

ardour does the latter (it used to do the former). when you take one
or more playlists and add automation data for gain levels, fx
parameters, and so forth, you end up with a complete specification for
the playback mix. when all this data exported as a file, industry
people sometimes call the result "an EDL". OMF is probably the most
popular format for this, though its proprietary (owned by Digidesign).

the approach outlined here does not equate to waveform editing, though
there are some overlaps in the kinds of things that can be done with
both approaches.

--p

Re: [linux-audio-dev] memory management

[Paul Davis]

>> i think this way lies madness, or at least possible foolishness.
>[snip]
>
>i do not understand. say i'm making a sw clone of the korg es-1
>'rhythm production sampler'. i need to edit the samples somehow, and
>then later apply some effects probably. what is the set of operations
>that i would want an editor to perform on the sample? (i don't know a
>better term than 'sample' here; perhaps i'll call it a clip.)
>
>- read in from a file
>- write to a file

if thats all you want to do, then use can use the time-honored unix
API's: fork(2) and exec(2).

API's like bonobo are designed to allow much tighter integration of
the different objects that the process model. you know this, sorry :)

>and all the interface is provided by the waveform editor 'control' (to
>use bonobo terminology). what is complicated about that? 

what does this waveform editor actually do? does it work like ardour,
and (almost) never actually modify anything on the disk? does it
always work like DAP, and always overwrite data on disk? does it
generate audio output and feed it to a playback engine directly, or
does it somehow pass it to the "master" object? does it handle
multichannel data? does it do disk readahead, and if so, how much?

each time you answer one of these questions, you narrow the space of
possibilities of what this waveform editor could possibly do. nothing
wrong with that at all, its a necessary step. but defining that
particular set of possibilities means that the resulting object is of
no use to a program that requires a different set.

to get more concrete: early on in ardour, i looked into embedding snd
as ardour's editor. initially, it looked quite promising: it was
already compilable as a widget, and i quickly got a version of ardour
working with the snd widget in its own window. but then i had to start
trying to figure out how to get snd to generate audio output when i
was working within it and wanted to listen to what i was doing. that
was hard, since snd didn't control the audio interface anymore the way
it does when its an application. then i ran into another problem, even
more severe: snd expected to be able to fetch all disk data on demand,
which wouldn't work in the type of situations i wanted ardour to be
useful for. finally, as i began to understand more about editing music
and sounds the way that ProTools, Nuendo, VST, Samplitude and others
make possible, i realized that an actual waveform editor wasn't really
what i wanted at all. the end result? snd is compilable as an
incredibly high function widget, but it wasn't at all useful a way to
edit audio in my particular application.

i strongly suspect that this would happen again and again regardless
of the embeddable objects design. 

go ahead and try to define what "editing the samples" means. good luck!

  i could be
>showing my ignorance here, but i sure would like to pull a waveform
>editor in as a bonobo control. i don't understand, for this application,
>your argument about 'similar' vs 'dissimilar'.

dissimilar: an application that handles data of type Y wants to 
   allow users to also work on data of type X within its
   general framework, and so uses an embeddable
   object to do so. Y and X do not intersect.

similar: an application that handles data of type Y doesn't do
   everything that could possibly be done with type Y.
   it wants to use an embeddable object to extend the set of
   operations it makes possible on data of type Y.

--p

Re: [linux-audio-dev] RazorPop job (equity)

[Juhana Sadeharju]

>
> How do you easily send 10MB in music and video
>files to a friend?  
>Today you can't.  Tomorrow you can, only
>with RazorPop.
[ and so on ]

Quite big claims.

Juhana

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Paul Davis]

>Q: Do the SCHED_FIFO bugs prevent a simple use of sched_setscheduler() to
>bump the priority of a thread that is reading and writing to OSS? I want the
>code to work on old systems as well as new.

No. The bug(s) you have heard about did not affect the use of
SCHED_FIFO. It affected the way the kernel scheduled kernel threads in
this scheduling class. It meant that what a thread expected from using
SCHED_FIFO wasn't being honored by the kernel.

>Q: Does SCHED_RR work better than SCHED_FIFO? Fewer bugs?

No. It doesn't work better or worse. The situation is more complex
than that. SCHED_RR is designed for situations where there are several
"real time" kernel threads and you wish to ensure that they all get
time on the processor, regardless of their own intentions. the RR
stands for "round robin". SCHED_FIFO is different in that once a
thread is running, it will run forever, or until it yields, blocks or
a higher priority SCHED_FIFO thread is runnable. its designed for
situations where there is either only 1 "real time" kernel thread, or
a set that are intended to do cooperative multitasking.

>Q: I have code that throttles back if I consume too much CPU time. Is that
>sufficient?

sufficient for what?

>Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
>should I use less?

its up to you. if you use the max value, its impossible for anyone to
ever kill you if your thread gets stuck in a loop. OTOH, since there
are no standard systems to kill you if your thread gets stuck in a
loop, thats somewhat besides the point right now.

--p

Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR

[John Lazzaro]

> I have heard reports that SCHED_FIFO has several bugs.

I test out SCHED_FIFO code under 2.2.17 daily, using buffer   
latencies in the 3ms range and doing work that isn't disk
intensive (i.e. sfront networking development, exercising
audio I/O, UDP send/receive, and moderately demanding 
floating-point CPU usage). And it works really well for me:
I can switch from being root to being a non-root, and hear
night-and-day differences in dropouts.

So, SCHED_FIFO wasn't always broken -- I haven't kept up
with the details of how it broke under 2.4 and whether or
not its truly fixed, but if your goal is to just get a 
system up where SCHED_FIFO is known to work in order to
do initial code debugging, 2.2.17 is known to work ...

--jl

-
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-

RE: [linux-audio-dev] problems creating/managing pthread stuff (audio-app related)

[Ivica Bukvic]

I'd prefer it to be a separate thread due to its time-critical nature.
Although, I must admit this is my first attempt at creating such
application, compounded with the first GUI-app creation, so I am trying
to tackle a lot of problems at the same time. That being said, I am
going to stick with my current design until I get the app up-and-running
to a point I can claim it is "useful." Following that, I'll most likely
sourceforge it and from then on, the sky's the limit :-).

Ivica Ico Bukvic, composer, computer consultant & audio designer
http://meowing.ccm.uc.edu/~ico/
[EMAIL PROTECTED]

"To be is to do"   - Socrates
"To do is to be"   - Sartre
"Do be do be do"   - Sinatra
"I am" - God

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Fred
Gleason
Sent: Monday, November 26, 2001 9:02 AM
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] problems creating/managing pthread stuff
(audio-app related)

On 21 Nov 2001, Ivica Bukvic wrote:

> Hi all! Currently I am working on an app that needs to have a timer
set
> up as a separate thread, but the problem is that I've been designing
the
> whole project in Kdevelop (using qt), and my main window is one big
> Instance of a class which also possesses a Method which is responsible
> for updating the Timer gui (i.e. milliseconds, seconds, minutes etc.).

Does it have to be a seperate thread?  Why not use GTimer?  e.g:

GTimer *timer=new GTimer(this,"timer");
connect(timer,SIGNAL(timeout()),this,SLOT(timer_handler()));
timer.start(interval);

Cheers!


|---
--|
|Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266
|
| Director of Engineering |1901 N. Moore Street|  FAX: 1-(703)-807-2245
|
| |Arlington, VA 22209 |  Web:
HTTP://www.wava.com|
|---
--|
| Logic is a way to go wrong with confidence.
|
|   --Robert Heinlein
|
|   "The Notebooks of Lazarus Long"
|
|---
--|

[linux-audio-dev] RazorPop job (equity)

[Dave Phillips]

Greetings:

  This may be of some interest to someone here.

Best regards,

== Dave Phillips

The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm
The Linux Soundapps Site at http://sound.condorow.net


 How do you easily send 10MB in music and video
files to a friend?  
Today you can't.  Tomorrow you can, only
with RazorPop.

Dave,

I was referred to you from another site...  

I want to introduce RazorPop.  We're developing a revolutionary way to
transfer music and video media files for consumers.  We're not
externally funded yet and need to develop product.  I seek a tech leader
and programmers who believe in our mission and can contribute to the
effort in exchange for equity.  

I appreciate any help or referrals you can provide whether you're
interested, can refer someone who might be, or can point me to good
sites where should I post this opportunity.

Best Regards,
Marc Freedman


__ 
Marc Freedman 
CEO
RazorPop
11620 Audelia Rd., Suite 117, Dallas, TX 75243 USA
Office  214.342.8095
Mobile  214.734.3583
Fax 707.221.0616
Email   mailto:[EMAIL PROTECTED]
Paging mailto:[EMAIL PROTECTED]
http://razorpop.com

The Next Generation Digital Music Service
Just Raz It! (TM)

Get the latest RazorPop news and job openings.  Send a blank email to   
mailto:[EMAIL PROTECTED] 

Proud sponsor of DallasPop - http://dallaspop.com
__ 

The reasonable man adapts himself to the world; the unreasonable one 
persists to adapt the world to himself. Therefore all progress depends
on 
the unreasonable man. -George Bernard Shaw, writer, Nobel laureate 
(1856-1950)

LP -> CD conversion WAS: RE: [linux-audio-dev] latest Snd screenshot

[STEFFL, ERIK *Internet* (SBCSI)]

> -Original Message-
> From: Mark Parker [mailto:[EMAIL PROTECTED]]
> 
> I am looking for a very specific use:
>   transfering LP's to Cd's and removing pops, clicks, 
> etc. in the process

  gramofile (or gramophile), there's a debian package for this program...

erik

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

[Jörn Nettingsmeier]

Paul Winkler wrote:
> 
> On Fri, Nov 16, 2001 at 08:50:23PM +0100, Jörn Nettingsmeier wrote:
> > just fyi, the  linuxdj site has repaired itself last night and i
> > have finally been able to update the news page.
> 
> Cool. I also took the opportunity to update the Audio Quality HOWTO.
> 
> > still no traces of benno however, and my mails remain unanswered.
> 
> let's hope Benno is OK!

after another mess-up at linuxdj.com, i have at long last heard from
benno again.
the problems are all sorted out and benno is alive and well, but he
is not currently checking his old address. unfortunately i didn't
have his private mail address, which is why he hasn't replied
earlier.


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

[linux-audio-dev] SCHED_FIFO versus SCHED_RR

[Phil Burk]

Hello,

I am working with a group on PortAudio, a simple cross-platform open-source
audio API. We currently support Windows, Mac, BeOS, SGI, and, of course,
Unix.

Folks have been reporting audio glitches even with a buffer size equivalent
to 100 msec. I have experimented with setting my thread priority to the max
for SCHED_FIFO and that seems to eliminate the glitches. I can get down to
around 5 or 10 msec latency on RedHat 7.2, even without any low-latency
patches. But I have to run as superuser.

I have heard reports that SCHED_FIFO has several bugs. I have searched the
web and read many posts about this but there are still unanswered questions.

Q: Do the SCHED_FIFO bugs prevent a simple use of sched_setscheduler() to
bump the priority of a thread that is reading and writing to OSS? I want the
code to work on old systems as well as new.

Q: Does SCHED_RR work better than SCHED_FIFO? Fewer bugs?

Q: I have code that throttles back if I consume too much CPU time. Is that
sufficient?

Q: Can I safely use the value from sched_get_priority_max(SCHED_FIFO) or
should I use less?

Thanks,
Phil Burk
JSyn,pForth,DSP,ASIC - http://www.softsynth.com
Portable Audio I/O   - http://www.portaudio.com
Interaction Server   - http://www.transjam.com

Re: [linux-audio-dev] memory management

[Andy Wingo]

On Mon, 26 Nov 2001, Paul Davis wrote:

> In message <[EMAIL PROTECTED]>you write:
> >On Mon, Nov 26, 2001 at 12:50:00AM -0800, Josh Green wrote:
> >> 
> >> I agree completely. But what we do need is a way to easily embed an
> >> editor with other audio type programs, such as Smurf :) Are we still of
> >> the opinion that this is not possible or worth while?
> >
> >Based on some mighmarish memories of the last time I did any Windows
> >programming, isn't that what OLE (now COM+?) is supposed to do, and isn't
> >Bonobo supposed to be the linux equivalent? I'm sure KDE has something
> >similar too.
> 
> i think this way lies madness, or at least possible foolishness.
[snip]

i do not understand. say i'm making a sw clone of the korg es-1
'rhythm production sampler'. i need to edit the samples somehow, and
then later apply some effects probably. what is the set of operations
that i would want an editor to perform on the sample? (i don't know a
better term than 'sample' here; perhaps i'll call it a clip.)

- read in from a file
- write to a file

and all the interface is provided by the waveform editor 'control' (to
use bonobo terminology). what is complicated about that? i could be
showing my ignorance here, but i sure would like to pull a waveform
editor in as a bonobo control. i don't understand, for this application,
your argument about 'similar' vs 'dissimilar'.

best regards,

wingo.

Re: [linux-audio-dev] memory management

[Joshua Haberman]

* To [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> * Christophe Baillon ([EMAIL PROTECTED]) wrote:
> > To treat big samples (40Mo for example) is it judicious to load the
> > whole file in only one buffer ?
> > If i want to insert an other sample of 5 Mo in the medium of the buffer,
> > should i cut the sample into a linked list of block memory, or should i
> > make a realloc() and a displacement of data in the block ?
> > 
> > Is there interesting link on the web about algorithms used by sound
> > applications ?
> 
> Audacity (audacity.sourceforge.net) breaks up audio data into blocks that
> are somewhere between 500k and 1MB and stores each of these into its own
> file in the temp directory.

I would be interested to know how this differs from schemes used by other
editors, if anyone is willing to briefly explain. For example I have
never heard of EDLs and I couldn't find a good explanation on the net.

Joshua

-- 
Joshua Haberman  <[EMAIL PROTECTED]>

Fwd: Re: [linux-audio-dev] SB Audigy Linux Drivers?

[Johan Ehnberg]

I'm also interested in this matter, and I found
"OSS 3.9.6-RC1 for Linux/FreeBSD/Solaris x86 announced"
with
"Beta Sound Blaster Audigy support!"
at
www.opensound.com

--johan "shadow eel" ehnberg

Re: [linux-audio-dev] memory management

[Vincent Touquet]

(cut)
>Bonobo supposed to be the linux equivalent? I'm sure KDE has something
>similar too.

Based on my very limited knowledge, I think it is KParts you are referring
to, cfr. http://developer.kde.org/documentation/tutorials/kparts/
ClassIndex: http://developer.kde.org/documentation/library/2.0-api/classref/kparts/
Demonstration: http://dot.kde.org/1000392920/

(these were the first hits from google on KParts ;)

kind regards
vini

Re: [linux-audio-dev] memory management

[Paul Davis]

In message <[EMAIL PROTECTED]>you write:
>On Mon, Nov 26, 2001 at 12:50:00AM -0800, Josh Green wrote:
>> 
>> I agree completely. But what we do need is a way to easily embed an
>> editor with other audio type programs, such as Smurf :) Are we still of
>> the opinion that this is not possible or worth while?
>
>Based on some mighmarish memories of the last time I did any Windows
>programming, isn't that what OLE (now COM+?) is supposed to do, and isn't
>Bonobo supposed to be the linux equivalent? I'm sure KDE has something
>similar too.

i think this way lies madness, or at least possible foolishness.
OLE/COM/CORBA/Bonobo are essentially about allowing dissimilar objects
to communicate in a structured way, including allowing the embedding
of "views" of an object within another "view". the "dissimilar" here
is key: we're talking about embedding, say, a spreadsheet view of some
data inside a text processor and its document.

but what josh has described above is about allowing essentially
*similar* objects to be embedded, and thats much more problematic. you
now have at least different controllers (and views) potentially
operating on the same data. this means that there has to be, as
Richard implicitly pointed out, some agreed upon definition of either
the internal data representation and/or some IDL defining legal
operations on the object and a way of being notified of changes to
it.if you take the IDL route (i.e. the OLE/COM/CORBA/Bonobo route),
then why bother to embed another chunk of code, when the operations
are already defined? all you gain is some view code, and thats
normally not very hard to do, especially in comparison to connecting
audio program 1 to audio program 2 via OLE/COME/CORBA/Bonobo.

--p

Re: [linux-audio-dev] memory management

[Paul Davis]

>We have libgtkwaveform f.i. which you can use to embed a simple (read:
>no large files, so sophisticated undo/redo) wave editor into any

actually, libgtkwaveform does support large files, files of any size
in fact. but it has no support for any editing operations of any kind
other than by telling it to redisplay the (presumably changed) data.

--p

Re: [linux-audio-dev] memory management

[Steve Harris]

On Mon, Nov 26, 2001 at 12:50:00AM -0800, Josh Green wrote:
> 
> I agree completely. But what we do need is a way to easily embed an
> editor with other audio type programs, such as Smurf :) Are we still of
> the opinion that this is not possible or worth while?

Based on some mighmarish memories of the last time I did any Windows
programming, isn't that what OLE (now COM+?) is supposed to do, and isn't
Bonobo supposed to be the linux equivalent? I'm sure KDE has something
similar too.

A quick search on google throws up:
http://www.gnome.org/gnome-office/bonobo.shtml

- Steve

Re: [linux-audio-dev] problems creating/managing pthread stuff(audio-app related)

[Fred Gleason]

On 21 Nov 2001, Ivica Bukvic wrote:

> Hi all! Currently I am working on an app that needs to have a timer set
> up as a separate thread, but the problem is that I've been designing the
> whole project in Kdevelop (using qt), and my main window is one big
> Instance of a class which also possesses a Method which is responsible
> for updating the Timer gui (i.e. milliseconds, seconds, minutes etc.).

Does it have to be a seperate thread?  Why not use GTimer?  e.g:

GTimer *timer=new GTimer(this,"timer");
connect(timer,SIGNAL(timeout()),this,SLOT(timer_handler()));
timer.start(interval);

Cheers!


|-|
|Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266   |
| Director of Engineering |1901 N. Moore Street|  FAX: 1-(703)-807-2245   |
| |Arlington, VA 22209 |  Web: HTTP://www.wava.com|
|-|
| Logic is a way to go wrong with confidence. |
|   --Robert Heinlein |
|   "The Notebooks of Lazarus Long"   |
|-|

Re: [linux-audio-dev] memory management

[Richard Guenther]

On 26 Nov 2001, Josh Green wrote:

> On Sun, 2001-11-25 at 16:44, Paul Davis wrote:
> > >If you are planning on editing very large files, I would say no, you
> >
> > and if you're not planning on editing large files, go home and find
> > something better to do. the world is too full of little toy editors
> > that can't handle audio samples larger than physical RAM+swap.
> >
> > for that matter, i echo richard's sentiments. we don't need another
> > sound editor. we need improvements to the ones already under
> > development. you'll learn more, and learn faster, and the world (and
> > you) will get a useful editor sooner.
>
> I agree completely. But what we do need is a way to easily embed an
> editor with other audio type programs, such as Smurf :) Are we still of
> the opinion that this is not possible or worth while?

We have libgtkwaveform f.i. which you can use to embed a simple (read:
no large files, so sophisticated undo/redo) wave editor into any
app while keeping its internal wave data representation. Possibly adding
a simple LADSPA host library on top of libgtkwaveform would help, too.

Anything more complex would require too much knowledge of the other
audio type program. You f.i. could link with parts of the glame source
and just call glame_waveedit_gui_new() from your program. But of course
you'd either need to use the glame internal wave representation in your
program or convert between the two.

Richard.

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

Re: [linux-audio-dev] memory management

[Josh Green]

On Sun, 2001-11-25 at 16:44, Paul Davis wrote:
> >If you are planning on editing very large files, I would say no, you
> 
> and if you're not planning on editing large files, go home and find
> something better to do. the world is too full of little toy editors
> that can't handle audio samples larger than physical RAM+swap.
> 
> for that matter, i echo richard's sentiments. we don't need another
> sound editor. we need improvements to the ones already under
> development. you'll learn more, and learn faster, and the world (and
> you) will get a useful editor sooner.

I agree completely. But what we do need is a way to easily embed an
editor with other audio type programs, such as Smurf :) Are we still of
the opinion that this is not possible or worth while?

> 
> --p
-- 
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)

Re: [linux-audio-dev] memory management

[Richard Guenther]

On 25 Nov 2001, Josh Green wrote:

> EDL lists is what broadcast 2000 uses
> (too bad its no longer being developed), ardour and glame I believe as
> well.

GLAME not really - the concept used there is more like the one Audacity
is using (as I can imagine from another mail to this thread, not by
reading the source).

Richard.

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